pgw#992 (P0): "free right now" is not a budget for K children's simultaneous peak

changelog.d/pgw992.md

@@ -0,0 +1,36 @@
+- **pgw#992 (P0): the compile pool stops treating a momentary free reading as a
+  simultaneous budget.** pgw#868 A4 replaced the pool's ~56 %-unobserved
+  per-entry estimate (9.9 GiB) with the entry children's own MEASURED
+  high-water (6.02 GiB) and divided the free-VRAM sample by it — `29.5 / 6.02
+  -> K=4`. On the first AOT mint ever to reach the compile phase on the real
+  path that killed the mint deterministically at entry 2 of 36: a 44.39 GiB
+  L40S holding a 9.54 GiB eager-serving parent (resident by pgw#784's
+  contract), the mint child's own 16.20 GiB pipeline and four ~6 GiB entry
+  children — 44.35 of 44.39 GiB, OOM on a 14 MiB allocation.
+- The premise was right and the arithmetic was wrong in one way: the free
+  sample is taken *before* the widened children exist and prices none of their
+  growth, and the two resident consumers went from 14.9 GiB at the sample to
+  25.7 GiB at the OOM. `_rewiden` now caps A4's grant by a budget taken against
+  the CARD — `total − resident co-tenant − this process's device high-water −
+  the tenant reserve when a serve goal exists` — with the co-tenant measured by
+  a `CardCensus` read at pool construction, before child one exists, which is
+  the only moment that subtraction means anything.
+- Every term is an observation and the bound is recorded whether or not the
+  widen happens, so a future OOM names which term was wrong instead of leaving
+  a reader to diff two pods that no longer exist. Deliberately NOT a larger
+  `DEVICE_RESERVE_BYTES` (§4.24): padding a constant moves the same unpriced
+  simultaneity onto the next card. Unreadable census ⇒ no widen.
+- **The bound is on every width, and it is not a statement about the divisor.**
+  The z-image contrast specimen — same code, `16.2 GiB free / 25.0 GiB per
+  entry (ESTIMATED) -> K=1` — shows the estimate only *accidentally* protected
+  that pod, so "prefer the measured peak" is precisely the change that turned
+  the safe case into the OOM, and "distrust the measurement" would be the same
+  error mirrored. The constructed width is therefore bounded too (floored at
+  K=1, the serial path the pool degrades to), and on the incident pod the two
+  compose: constructed `K 2 -> 1` on the 9.9 GiB estimate, then `K 1 -> 2` once
+  the 6.02 GiB measurement lands. The measurement still moves K; it cannot move
+  it past the card.
+- Read from the DEVICE, never summed from what the pool believes is loaded:
+  the same z-image pod showed **16.2 GiB free on an 80 GB card whose static
+  slot sum is 53.3 GiB** — ~9 GiB of CUDA context, allocator fragmentation and
+  child overhead that no catalog arithmetic can see.