docs(prod): iGPU ruled out as the cause; CORRECT my last_pfn misreading

Operator asked whether node 2's missing memory could be reserved for integrated graphics.
TESTED, and no: /proc/iomem shows 'c8800000-cc7fffff : Graphics Stolen Memory' = EXACTLY 64 MiB,
matching the BIOS Video Memory Size=64 MB setting, and it sits BELOW the 4 GiB line. The UHD 630
(i915 bound) takes precisely what it is configured to take. It cannot account for 13.3 GiB and is
not even in the affected address range.

CORRECTION to my own analysis, prompted by checking that hypothesis properly: I cited the
'last_pfn revised DOWN from 0x42f800 to 0xc3c10' line as evidence of a memory cap. That was a
MISREADING. x86 boot prints last_pfn twice — first max_pfn from the full e820, then max_low_pfn,
the end of RAM below 4 GiB. The e820 low usable region ends at 0xc3c0ffff, so the next PFN is
exactly 0xc3c10, which is the second value observed. It matches to the byte and is normal on any
machine with more than 4 GiB. I presented a routine boot message as a smoking gun, and the
'memory remapping above 4 GB not being applied' signature claim rested partly on it.

The real anomaly is narrower than first stated: the Normal zone is 'present' but 'managed 0',
13.3 GiB is reserved, and nothing in the boot log explains by what. Ruled out so far: DIMM health,
firmware inventory, memory-remap settings (none exist on this platform), MTRR trim, iomem
registration, and now integrated graphics. Leading remaining hypothesis is stale memory-training
data cached by Fast Boot — testable with one F10 toggle.

Serves: R-ENV-03. Task: T-7.1.

infra/PROD-PROVISIONING.md

@@ -54,15 +54,25 @@ more RAM until this is understood** — see the warning at the end.
 | DMI (`dmidecode -t memory`) | **16 GB Samsung M471A2K43DB1-CTD in DIMM1 @ 2667 MT/s**, DIMM3 empty |
 | BIOS e820 map | reports ~16 GiB usable, incl. `0x100000000-0x42f7fffff` |
 | Kernel summary | `Memory: 2568544K/16546088K available (13958980K reserved)` |
-| `last_pfn` | revised **down** from `0x42f800` (~16.7 GiB) to `0xc3c10` (~3.06 GiB) in early boot |
+| `last_pfn` | two values, `0x42f800` then `0xc3c10` — **NOT a cap**, see the correction below |
 | Zones | `Normal` zone `present 3340288` pages (~12.7 GiB) but **`managed 0`** |
 | `MemTotal` | **2,753,284 kB ≈ 2.6 GiB** |
 | Memory blocks | 127 online, 128 MiB block size |
 
 **The DIMM is healthy.** It is present, correctly identified, and running at its rated speed. The
 kernel *sees* all 16 GB and then reserves 13.3 GiB of it. Everything below ~3 GiB is usable and
-everything above 4 GiB is present-but-unmanaged — the classic signature of **memory remapping
-above 4 GB not being applied**, not of failing memory.
+everything above 4 GiB is present-but-unmanaged.
+
+> **CORRECTION (2026-09-01).** An earlier version of this section cited the `last_pfn` line as
+> evidence of a memory cap, and called the pattern the signature of "memory remapping above 4 GB
+> not being applied". **The `last_pfn` reading was wrong.** x86 boot prints `last_pfn` twice: first
+> `max_pfn` from the full e820, then `max_low_pfn` — the end of RAM *below 4 GiB*. The e820 low
+> usable region ends at `0xc3c0ffff`, so the next PFN is exactly `0xc3c10`, which is the second
+> value observed. It matches to the byte and is entirely normal on any machine with >4 GiB. A
+> routine boot message was presented as a smoking gun.
+>
+> The real anomaly is narrower than first stated: the `Normal` zone is `present` but `managed 0`,
+> 13.3 GiB is reserved, and **nothing in the boot log explains by what**.
 
 Node 1 is the control: **identical** HP EliteDesk 800 G5 Mini, **identical** BIOS R21 Ver. 02.26.00,
 identical i7-9700T — and it addresses its full 31 GiB. So this is not a firmware-version defect; it
@@ -90,6 +100,11 @@ What the comparison ruled OUT as the cause:
   which rules out the classic "BIOS bug: MTRRs don't cover all of memory, losing N MB" path.
 - **`/proc/iomem` registers `100000000-42f7fffff` as `System RAM`** and 127 × 128 MiB memory
   blocks report `online`. The memory reaches the kernel and is then reserved.
+- **Integrated graphics is NOT the cause** (operator hypothesis, tested 2026-09-01). `/proc/iomem`
+  shows `c8800000-cc7fffff : Graphics Stolen Memory` = **exactly 64 MiB**, matching the BIOS
+  `Video Memory Size=64 MB` setting, and it sits **below** the 4 GiB line. The UHD 630 with `i915`
+  bound takes precisely what it is configured to take. It cannot account for 13.3 GiB, and it is
+  not even in the affected address range.
 
 Real BIOS differences found (node 1 = works, node 2 = broken):