mechanism: overlap check reads engine slot regs (SMN 0x49007a00), not the protected-DRAM table; 0x105d stages only (no SVC 0xA1)

Confirmed sub_E15EF0 (SVC 0x7B read) and sub_E218FC (SVC 0x7C write) use the SAME register block
0x49007a00 = the transfer engine's own 16 slot descriptors. The overlap check compares the chosen
base against other in-flight transfer slots (owner-scoped), NOT the dword_E264B0 protected-DRAM
table. So gap #3 answered statically: the window is NOT fenced on the 0x105d path (only on 0x1006).
Also: spirom_xfer path has no SVC 0xA1 commit -> 0x105d stages a descriptor but moves no data, so a
single shot is inert and safe to probe. Updated the diff doc.

1 files changed, 17 insertions, 4 deletions

diff --git a/fw/DIFF-SPIROM_XFER-51-VS-54-TMR-FIX-SCOPE.md b/fw/DIFF-SPIROM_XFER-51-VS-54-TMR-FIX-SCOPE.md
index a95e829..279a6a9 100644
--- a/fw/DIFF-SPIROM_XFER-51-VS-54-TMR-FIX-SCOPE.md
+++ b/fw/DIFF-SPIROM_XFER-51-VS-54-TMR-FIX-SCOPE.md
@@ -67,10 +67,23 @@ only by the 16-slot region-overlap check, not by the protected-DRAM-window fix.
    `base` = desc+0 (64 KB-aligned, <48-bit), `len` = desc+8, `region_id` = desc+16, out-handle
    written at desc+20. Must find a `(base,len,region_id)` that passes validation and actually triggers
    the DMA, then read back the result. `0xffff000f` is the expected reject for the all-zero case.
-3. **Does the 16-slot overlap check fence the interesting targets?** It is a different table from
-   `dword_E264B0`; it is runtime-populated, so whether a sensitive physical destination is covered is
-   a hardware-measurement question. The overlap check -- not the absent window check -- is the real
-   remaining guard to characterize.
+3. **Does the 16-slot overlap check fence the interesting targets? -- answered statically (NO).** The
+   overlap check reads slot ranges via `sub_E15EF0` = `SVC 0x7B` on register block **SMN
+   `0x49007a00`**, the transfer engine's OWN 16 slot descriptors (same block `sub_E218FC` programs via
+   `SVC 0x7C`). It is NOT the `dword_E264B0` protected-DRAM table. So the only guard on the `0x105d`
+   path compares the chosen base against *other in-flight transfer slots* (owner-scoped), and never
+   against the protected window. The window is consulted only on the `0x1006` path. Remaining: a
+   hardware shot to confirm a valid descriptor stages (status 0) and that a window-pointing base is
+   not overlap-rejected.
+
+## MECHANISM: `0x105d` stages a transfer-engine descriptor; it does NOT move data
+
+`spirom_xfer` path SVCs: `0x5e`/`0x5f` (critical section), `0x7c` (program slot regs via
+`sub_E218FC`), `0x66` (getpid in `sub_E17EF4`), `0x7b` (slot readback via `sub_E15EF0`). **No `SVC
+0xA1`** (the VULN doc's commit/kick) anywhere in the path. So one `0x105d` call reserves a slot and
+writes the engine's descriptor registers (base-page, end-page, mode, param at `0x49007a00 +
+24*handle`) but never commits -- no DMA executes until a separate commit opcode runs. A single shot
+is therefore inert (stage-only), which makes empirical probing of the destination guard safe.
 
 ## HARDWARE CONFIRMATION (gap #1 closed) -- `0x105d` is reachable from GCP on stock `.54`