docs/04-real-render-walls: SESSION 132 section 12 - the live utility ring is PROVEN in guest RAM (walk-confirmed per-run pages 0x11623d000/0x104b55000 with the 14-entry content the sweep decodes; the vidmem 0xa0000 'ring' was a false-positive autopin whose entry0 push reads all-zero and which the pump skipped after 39 rescues); the fixes (dead-entry guard + cross-aperture USERD + per-client util witnesses + op-level copyent) and their verification (r760: ring rc=0 on the live RAM page, live entry reads, VKFRAME_DONE 3 frames); the two LID uploads are the driver's zero buffers by design (256 B zero buffer + 12288 B CE fault buffer) while the GR channel's LID carries the real param bank; the code VA (prog=0xdfd8feb900) maps to a ROTATING code pool (0x62b900 -> 0xc8b000) whose lat entry can go stale and whose pages are empty - the SASS delivery shape (C5C0 0x3800/0x39C8 runs) and the walk-first code-VA resolution are the next two gates

1 files changed, 78 insertions, 0 deletions

diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index 56b5e11..b3cbc20 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -334,3 +334,81 @@ stale-session page); (2) trace where the live client's upload writes go
 (the map shows they are NOT in the first 256 MB of the shadow - check the
 guest's own view of the client's staging BOs during the upload window);
 (3) the descriptor/operand wiring (`n_data=0`) after that.
+
+## 12. UPDATE 2026-10-26 (SESSION 132): THE LIVE RING IS PROVEN (guest RAM, walk-confirmed); the vidmem "ring" was a false-positive pin whose dead entry the pump skipped 39 times; the two LID uploads are the driver's zero buffers by design; the code VA's mapping rotates and the shadow's lat cache can go stale
+
+**The live ring is in guest RAM and the sweep's decode was right.**
+`walk_probe 0x4020000` (the client's own page tables, vas[0]
+`h=0xfade0002 pdb=0x114039000`) resolves the utility channel's GPFIFO VA
+to **guest RAM** (PA `0x11623d000` on r759; the page moves per run:
+`0x104b55000` on r761) and its content is the 14-entry ring the sweep
+decodes: entry0 -> push `0x4000000` len `0x8bc` (the methods), entry1 ->
+the 256 B payload slot `0x4250000`, entry8 -> the 12288 B payload slot
+`0x4250110`, ... - all pushes inside THIS client's own allocation window
+(`PREV149-OUT ... off=0x4000000/0x4020000/0x4060000` in the client's own
+VIDHEAP log). The decoded ring is live content, not a stale page.
+
+**The vidmem "ring" (PA 0xa0000) is a false-positive autopin.** On r759
+the VRAM shape scan found the channel's REAL USERD at vidmem `0xb0000`;
+the userd-derived candidate loop then tried `0xb0000 - 0x10000 =
+0xa0000`, whose entry0 (`push 0x120100000/40` - the CE-pool push
+pattern) passed the plausibility gate and whose USERD probe hit the real
+0xb0000 block, so the pin landed. The pinned entry's push reads all-zero
+through every source; the pump retried 39 times and logged `skipping
+stale entry h=0xbeef0100 va=0x120100000 len=40 after 39 failed rescues`,
+while `sema_probe 0x4020000` then answered the wrong page
+(`pa=0xa0000 aperture=vidmem`) and poisoned every later read (the sweep
+included). Section 10's "stale session page" conclusion was this pin, not
+the sweep.
+
+**Fixes landed (commit `72de0bed`).** (1) `svc_ring_entry_dead` +
+`svc_ring_walk_live`: a candidate whose entry0 push provably reads
+all-zero through the client's page tables is rejected when the VAS walk
+resolves the ring VA to a page with a live entry (applied at the
+userd-derived, FB-convention and existing-pin paths; the walk cannot vote
+for itself); (2) `svc_gr_ring_candidate` rejects dead-entry candidates
+and accepts the channel's known USERD cross-aperture (the driver places
+GPFIFO and USERD independently: ring in guest RAM, USERD in vidmem); (3)
+the util sweep arbitrates a dead channel-path ring entry against the
+direct VAS walk per slot; (4) the util-dec/util-sweep witness budgets and
+their dedup keys are per-client now (reset in `svc_session_flush`); (5)
+`sema-copyent` logs once per copy OP, not per row - one 480-row frame
+copy had exhausted the 128/session budget and hidden every later copy.
+Verified on r760/r761: `sema-chan: h=0xbeef0100 ... ring rc=0
+pa=0x108cba000 ap=1` (the live RAM page), `sema-rdw: h=0xbeef0100
+va=0x4000000 len=2236 rc=0`, the sweep decodes the live 14 entries, the
+fence fold releases fire, and the client completes (`VKFRAME_DONE
+frames=3 640x480 saved=3`, `VKFRAME_IDLE ok`).
+
+**The two utility-channel LID uploads are the driver's zero buffers by
+design, not the SASS.** Live decode (r760): i=0 -> `dst=0x423f000 ll=256
+lc=1 zero=1` (256 B = `GF100_ZERO_BUFFER_SIZE`) and i=8 ->
+`dst=0x4448000 ll=12288 lc=1 zero=1` (12288 B = the CE fault method
+buffer size). The payload slots (`0x4250000` -> RAM `0x116219000`;
+`0x4250110`) read zero for the whole client run - the driver never
+writes them. The GR channel's own LID entry DOES carry a real payload
+(`dst=0x4b86020 ll=1568 zero=0` - the launch param bank at `param=
+0x4b86000 size=0x1900`), which proves the arm works with real bytes on
+this boot too.
+
+**Where the code page stands.** `prog=0xdfd8feb900` (the captured
+launch): `sema_probe` answered vidmem `0x62b900` early in the run while
+`walk_probe` answered vidmem `0xc8b000` later - the driver's code-buffer
+mapping ROTATES (a code pool), and the shadow's learned lat entry for the
+VA can go stale. Both pages read zero in the shadow: the driver's code
+upload has not been observed on any decoded path (no LID, no CE copy -
+the only `sema-copyent` op of the whole run is the 480-row frame
+copy-out `dst=0x50b0000 src=0xdfd8d60000`, which executes `rc=0
+bytes=0x12c000` and correctly copies the still-empty image). The
+remaining question is the SASS delivery shape for the C5C0 compute path
+(section 6's `0x3800/0x39C8` code-run/data-port semantics) and the stale
+lat preference for the rotating code VA.
+
+**Next steps (ranked).**
+1. Resolve the code VA through the VAS walk at launch time (the walk is
+   the live truth; the lat entry goes stale as the pool rotates) and
+   watch the code page the QMD actually names.
+2. Find the SASS delivery: dump the C5C0 section's `0x3800/0x39C8` runs
+   with a bounded methods witness while the client is live (the params
+   arrive by LID; the code must arrive by a sibling path).
+3. Then the `n_data=0` descriptor/operand wiring (section 8).