vgsp-gr: move win0 shadow pool clear of the data bounce window (matmul C rows 0..31)

m150 grew the GR data bounce window to 208 pages at main-PT slots
0x110..0x1df but left the win0 QMD shadow pool at VA 0x190000 (slots
0x190..0x197) - inside the new window. The win0 plant is unconditional on
every gsp_phys_rmcall_pdb_build() and runs after the one-shot bounce
plant, so it hijacked the PTEs for bounce pages 128..135, which hold the
first 8 pages of the third operand. victory_matmul's C rows 0..31
(8 pages x 256 floats = 8192 elements) were written into the shadow pages
and lost: MATMUL bad=8192, copy-out '56 changed by engine (first bi 136)'.

Move GSP_PHYS_RMCALL_VA_GR_SHADOW0_BASE to 0x1e0000 (slots 0x1e0..0x1e7),
directly above the last bounce/mail/marker page (0x1df000) and below the
0x200000 guest scratch window; both the plant and the launch-time shadow
VA derive from the macro. Add a static_assert so any future bounce growth
cannot silently re-introduce the overlap, and correct the stale slot-range
comments/logs (0x108..0x10f -> the current range).

Evidence: /tmp/opencode/dmesg-r143-mailmatmul.log (main PT[190..197] =
win0 chunk DMAs; 'window[160] reloc=0x1b0000 changed=1', 'window[128]
reloc=0x190000 changed=0'; MATMUL bad=8192). Live validation pending: a
fresh cycle's victory_matmul must print bad=0 STATUS OK.

1 files changed, 27 insertions, 0 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index fc210fb..d62b16b 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -189,6 +189,33 @@ isolation, performance, portability).
      repeat-run plus concurrent/simultaneous validation. Active front:
      the multi-client battery on the physical backend plus launch-latency
      robustness.
+     **Update 2026-10-14 ~15:40 (afternoon wave, r140-r143):** the full fix
+     set is committed and pushed (HEAD `17393a74`: ring depth `074f493c`,
+     scrubber `624438bb`/`80af379d`, bounded fresh-entry launch retry
+     `6b090f70`, 208-page budgeted data window `fce5ab8d`/`4a23c196`). r142:
+     c1 `victory_mail` and c2 `smiley` GREEN; c3 `victory_matmul` FAIL
+     (all-wrong operands - the three 256 KB operands resolved only ~32 of the
+     needed 64+ pages each); launch counters `ok=86 failed=10 retries=4`
+     (the retry recovers a subset of the cold-context timeouts silently);
+     then `victory_saxpy`/`memcpy_roundtrip` stalled and the guest SSH wedged
+     - the intermittent stall/wedge class survives. r143 (live at this
+     check, same fix set): c1 green within ~2 min; c3 matmul launched and
+     improved to `bad=8192` of 65536 with a non-zero checksum (operand
+     resolution now 68/64/64 pages) - STATUS FAIL. **Root cause found
+     (sub-agent, evidence-grounded): the win0 QMD shadow pool base was still
+     `0x190000` (main-PT slots 0x190..0x197), which lies INSIDE the enlarged
+     208-page bounce window (`0x110000..0x1df000`); the win0 plant runs on
+     every `pdb_build()` while the bounce plant is one-shot, so win0 stole the
+     PTEs for bounce pages 128..135 = C rows 0..31 = exactly `bad=8192`. Fix
+     landed (unvalidated live at pause): `GSP_PHYS_RMCALL_VA_GR_SHADOW0_BASE`
+     moved to `0x1e0000` (slots 0x1e0..0x1e7, above the mail/marker pages,
+     below the 0x200000 guest window) plus a `static_assert` invariant and
+     comment/log corrections.** Ranked next blockers: (1) the 256 KB operand
+     data-path placement; (2) the intermittent client stall/wedge class
+     (the top reliability blocker; needs the stalled-client capture);
+     (3) the cold-context launch race (cold GR-sem pre-warm designed);
+     (4) then multi-mdev, two guests, VRAM sizes and the concurrent/full
+     soak. Host clean, GPU green, no reboots.
 - **Guest frontier: FIRST GREEN END-TO-END GUEST CUDA, NOW UNDER HARDENING
   (2026-10-04 ~16:20; hardening 2026-10-05 overnight).** The emulation-only
   ("no-claim") campaign runs an unmodified guest CUDA program to completion