re: decode the trigger node -- and withdraw two of my own claims about it

The reader is sub_8226E220, called by the per-frame drain sub_8226D740 as
(phase+272, six out-params).  It pops one node and copies seven payload fields out.
Built-in 25, the appender, writes exactly those seven offsets:

    +0   local[4]  -- the unit          +24  the constant 1
    +4   local[12]                      +28  local[12] again
    +8   computed                       +32  --
    +16  a DOUBLE from local[16]

Neither side was derived from the other, so the agreement is the check.  Container:
+16 head, +20 pending count -- which matches the count isl-builtins.md watched live at
phase+272+20 from a completely different direction -- and +24 a cursor.

WITHDRAWN, from the previous commit: "the drain spawns from [node+112]".  r31 = r1 -
256, the stack frame, so +112 is an output slot and not a node field.

REFUTED, the follow-up hypothesis that the trigger carries the routine offset and so
names the code nothing else starts: payload+28 is local[12], and across all 25 call
sites disc-wide those values are the small integers 1 through 12 -- 1 of 25 (4.0%)
land on the instruction stream against a 16.0% control, and none are unreached
run-starts.  Below chance.  My first version of that test used n=2, Stage 02 only; it
happened to agree, but two samples could not have supported it either way.

One correction in the other direction, to the corpus: isl-builtins.md withdrew
sub_8226E458's link to the trigger queue on the grounds that "the argument is
lwz r4, 324(r29), the unit array, not the trigger container".  That is the SECOND
argument; the first is r26 = phase + 272, set twelve instructions earlier.  The drain
does operate on the container.  What sub_8226E458 does to it remains unread, so only
the argument is corrected, not the conclusion.

All artefacts regenerate byte-identical; documentation only.

Still open: what local[12] indexes; what the drain actually spawns, since [stack+112]
is filled from payload+28 yet the spawner wants a code offset, so some step in that
chain is not what I read; and what starts the ~15% of unreached code.

docs/re/BACKLOG.md

@@ -98,6 +98,27 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   the trigger queue at `phase+272`; that is the exact over-reach the corpus already
   withdrew once, so it is not asserted.
 
+* ✅🔴 **(2026-08-27) THE TRIGGER NODE IS DECODED — and two of my own claims are
+  withdrawn. [structures/isl-trigger-node](structures/isl-trigger-node.md).**
+  The reader is `sub_8226E220`, called by the drain `sub_8226D740` as
+  `(phase+272, …6 out-params)`. **Writer (built-in 25) and reader touch the same
+  seven payload offsets** — +0 `local[4]` (the unit), +4 and +28 `local[12]`, +8
+  computed, +16 a **double** from `local[16]`, +24 the constant 1, +32 — neither
+  derived from the other. Container: +16 head, **+20 pending count** (matching the
+  count `isl-builtins.md` watched live at `phase+272+20`), +24 cursor.
+  🔴 **WITHDRAWN: "the drain spawns from `[node+112]`"** — `r31 = r1 − 256`, the
+  STACK FRAME; `+112` is an output slot.
+  🔴 **REFUTED: the trigger carries a routine offset.** `payload+28` = `local[12]`,
+  and across **all 25 sites disc-wide** those are the small integers **1…12**:
+  **1/25 = 4.0 % land on the instruction stream vs a 16.0 % control**, 0 are
+  unreached run-starts. ⚠️ My first version of that test was **n=2** (Stage 02
+  only) — same answer, but unsupportable either way.
+  ✅ **And one correction TO the corpus:** `isl-builtins.md` withdrew
+  `sub_8226E458`'s link to the trigger queue by reading its SECOND argument
+  (`[phase+324]`); the FIRST is `r26 = phase + 272`, set twelve instructions
+  earlier. The drain does operate on the container — what `sub_8226E458` does to
+  it stays unread. 🟡 What starts the ~15 % of unreached code: still open, not this.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the