re: what appends a trigger node -- not found, recorded as such

Three approaches, none successful. sub_8226E160, earlier flagged as 'enqueue a
pending trigger', has exactly one caller and is a specific operation rather than
the general append. Writes to the count at +20 inside the container code number
only four, and all four are part of a block initialisation (stw to 0/8/12/16/20/
24 in consecutive instructions) in sub_8226E7D8 and sub_8226E930 -- constructors,
called from 0x8226E560 and from ScriptMission's own constructor at 0x822608A0.

So the increment that takes the count 0 -> 1 -> 2, which is measured live, does
not appear as a plain stw to 20(rM) anywhere in the container's code. It is
inlined, uses another addressing form, or lives somewhere I have not looked.

Recorded as not found rather than guessed: inferring from the shape of nearby
functions is exactly what produced the 'push' mislabel last iteration.

Names the approach that would settle it: a gdb watchpoint on
ScriptPhase+272+20 during a live mission. The address is known at runtime, the
count demonstrably changes within ~2 minutes, and a watchpoint reports the
writing instruction directly instead of inferring it from static shape.

docs/re/structures/isl-builtins.md

@@ -338,3 +338,33 @@ So built-in 100 *clears* the trigger queue and then rebuilds the thread list via
 mine, not the disassembly's. `xrefs` gives it two callers: `0x82265DD4` (vt2,
 the script side) and **`0x8226D420`, an engine site** — so the engine clears it
 too. What actually *appends* a node is still unidentified.
+
+
+## 🔴 What appends a trigger node — NOT FOUND this iteration
+
+Three approaches, none of which produced the appender:
+
+* **`sub_8226E160`**, flagged earlier as "enqueue a pending trigger", takes a
+  `double` plus several pointers, rejects `arg == -1`, and has **exactly one
+  caller** (`0x8226A044`). It is a specific operation, not the general append.
+* **Writes to the count at `+20`** inside the container code
+  (`0x8226DF00–0x8226F200`) are only **four**, and all four are part of a
+  *block initialisation* — `stw` to `0, 8, 12, 16, 20, 24` in consecutive
+  instructions, in `sub_8226E7D8` and `sub_8226E930`. Those are **constructors**
+  (callers `0x8226E560` and `0x822608A0`, the latter inside `ScriptMission`'s
+  own constructor), not increments.
+* So the increment that takes the count 0 → 1 → 2 — which is **measured, live**
+  — does not appear as a plain `stw rN, 20(rM)` anywhere in the container's own
+  code. It is either inlined into a caller, uses a different addressing form
+  (`stwx`), or the node count is maintained somewhere I have not looked.
+
+**Honest state:** the queue's structure, its live count and its node chaining are
+verified; what writes a node into it is not identified, and I do not have a
+candidate I believe. Guessing from the shape of nearby functions is what produced
+the "push" mislabel last iteration, so I am not repeating it.
+
+**The approach that would settle it** costs more but is unambiguous: a **gdb
+watchpoint on the count word** during a live mission. The address is known at
+runtime (`ScriptPhase + 272 + 20`), the count demonstrably changes within ~2
+minutes of flight, and the watchpoint reports the writing instruction directly
+instead of inferring it from static shape.