docs/04-real-render-walls: SESSION 133 section 13 - the SASS delivery shape is FOUND (the driver embeds the program bytes INLINE in a CE LAUNCH_DMA push: in=0x120a00004 -> out=0x205000, 4096 B/run; the Vulkan CE channels carry the same-shaped entries) and the three gates that keep the copies from running are named: the CE ring/USERD boot-lottery (FB convention matched r763 only; the real USERDs sit at 0xfee00/0xff000/0xff200 so the rings are at unaligned offsets like 0xefe00), the VAS age-out vs CE grace race (sema_vas_cand_ms=5000 registers at +5s), and the volatile ring/USERD content that a periodic shadow scan misses; next steps: USERD-shape-derived ring resolution or first-submission latch, then the inline copies and the n_data wiring

1 files changed, 55 insertions, 0 deletions

diff --git a/docs/04-implementation/04-real-render-walls.md b/docs/04-implementation/04-real-render-walls.md
index b3cbc20..3bad12e 100644
--- a/docs/04-implementation/04-real-render-walls.md
+++ b/docs/04-implementation/04-real-render-walls.md
@@ -412,3 +412,58 @@ lat preference for the rotating code VA.
    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).
+
+## 13. UPDATE 2026-10-26 (SESSION 133): THE SASS DELIVERY SHAPE IS FOUND - the driver embeds the program bytes INLINE in a CE LAUNCH_DMA push and copies them to vidmem; the CE channel's ring/USERD resolution is the boot-lottery gate that keeps the copies from running
+
+**The delivery shape (decoded from the CE channel).** A CE-class channel
+(eng=11) carries, as entry[4] of its ring, a push whose method stream is a
+LAUNCH_DMA copy with the SASS bytes INLINE:
+
+```
+sema-chan: entry[4] h=0xcaf00012 eng=11 raw=0021340120a00000 va=0x120a00000 len=8500
+sema-bigrun: h=0xcaf00012 push=0x120a00000 off=0x0 hdr=0x64000002 op=3 cnt=1024 subch=0 addr=0x8
+sema-lda: h=0xcaf00012 eng=11 push=0x120a00000 dma=0x00002181 xfer=1 dstphys=1 srcphys=0 out=0x205000 in=0x120a00004 line=4096 have_out=1 have_in=1
+sema-opadd: h=0xcaf00012 type=1 dst=0x205000 src=0x120a00004 bytes=4096 ap=0 src_ap=0 phys=1 src_phys=0
+```
+
+The source is the push itself (`in=0x120a00004`, right after the method
+header) and the destination is a vidmem VA (`out=0x205000`, then
+`0x206000`, ... 4096 B per run) - the engine-side "download program
+range" path. The Vulkan client's CE channels carry the SAME shaped
+entries (r763: `sema-utildec: h=0xbeef0101 i=4 va=0x120a00000 len=0x2134`,
+19 entries swept) - so the SASS delivery is a CE inline copy, not the
+utility-channel LID entries (those are the driver's zero buffers,
+section 12).
+
+**Why the copies never ran (three gates).** (1) The CE channel's ring and
+USERD live in VIDMEM and resolve only by boot-lottery: the FB convention
+matched on r763 (`auto-pinned ring h=0xbeef0101 rank=0 va=0x4100000 ->
+fb 0x80000 (entry0 va=0x120000000 len=40)`; entries then decoded and the
+frame path ran) but read zeros on r765/r767/r768 - the USERD shape scan
+instead finds the channel blocks at 0xfee00/0xff000/0xff200 (r767/r768),
+so the rings sit at unaligned offsets like 0xefe00. (2) The CE push VAs
+(0x120000000+) need the client's VAS registered: the parked
+COPY_SERVER_PDES candidate only registered at +15 s (age-out,
+`sema_vas_cand_ms`) while the entry hold grace (`sema_ce_grace_ms`,
+8000 ms from the cycle) expired first - r763 logged `skipping stale
+entry h=0xbeef0101 va=0x120000000 len=40 after 8000 ms grace` and
+`sema-pushfail: va=0x120a00000 ... trusted_rc=-2 ipin=0` for the copy
+pushes. Setting `sema_vas_cand_ms=5000` registers the VAS at +5 s
+(verified: `VAS 0xfade0002 ... registered UNVERIFIED after 5000 ms
+parked`) but the ring gate still blocks. (3) The shadow ring scan
+fallback (commits `52ef3f9d` + `2735180a`: 0x100 stepping, rate-limited
+retry, entry0 shape + USERD probe at +0x10000/+0x2000/+0x1000) found no
+candidate on r768: the ring/USERD content is volatile at scan instants
+(a `find_userd` read shows `off=0xfee00 get=11 put=11` while a
+`dump_vidmem 0xfee00` one second later reads zero), so a periodic scan
+misses the window.
+
+**Next steps (ranked).** 1. Derive the CE ring from a USERD found by its
+own shape (put at +0x8c, get at +0x88 - the `find_userd` scan already
+does this) instead of scanning for ring entries: for every USERD-shaped
+block, try ring = userd - {0x10000, 0x2000, 0x1000} and validate entry0
++ the probe. 2. Or latch the ring at the first CE submission (the ring
+content appears exactly when the driver writes entry0). 3. With the ring
+latched and the VAS at +5 s, verify the inline copies execute
+(`sema-lda`/`sema-opadd`/`sema-copyent` with the code dsts) and the code
+page gets content; then the `n_data` descriptor wiring (section 8).