re: corrected poke also does nothing -- and the method lacks a positive control

rec+4 = 0 (the early-exit path built-in 69 actually tests) sticks for 60s with
all three squadrons poked, and neither the phase nor +16 changes. +16 stayed 2
while the handle it derives from read zero.

Leading explanation: the phase-1 condition coroutine is not polling. Both pokes
persist untouched and nothing recomputes anything, which fits the polls at
0xF524 living in a coroutine that only runs when a trigger starts it
(built-in 1, fed from [phase+272]).

But the honest problem is bigger: two pokes have now produced no observable
effect and I cannot tell 'the game ignored the write' from 'the write never
reached the game'. The stick test only proves the value persisted in the
shared-memory FILE, not that Canary's guest sees it. That control should have
come first, so both null results are downgraded to INCONCLUSIVE rather than
evidence about the condition.

Next: poke something with a visible effect (player hull, a HUD counter) and
confirm it on screen before trusting any further null result. What still stands
from these runs is only what was observed rather than poked -- the arrivals,
ADN111's destruction, and the mission-over branch.

docs/re/script-runtime-probe.md

@@ -280,3 +280,45 @@ made a small index look like a live object.
 guess, given the values), and how to make the condition actually re-evaluate.
 Firing the trigger — built-in 100 pushes onto `[phase+272]` — is the next thing
 to look at.
+
+## 🔴 The corrected poke (`rec+4 = 0`) also does nothing — and I have no positive control
+
+Built-in 69 reads `rec+4`, not `rec+16` (see
+[isl-builtins](structures/isl-builtins.md)), so the corrected simulation of
+"this squadron is gone" is `rec+4 = 0`, which takes the handler's documented
+early exit. Ran it with all three squadrons active:
+
+```
+STICK TEST on ADN110 +4: was=26 wrote=0 after2s=0 -> STICKS
+poked all 3
+  [+5s .. +60s]  phase=1 finished=0  states={ADN110:2, ADN111:2, ADN112:2}
+```
+
+**No phase end, and `+16` never changed either** — it stayed 2 for a full minute
+while the handle it is supposedly derived from read zero.
+
+### 🟡 The leading explanation: the condition coroutine is not running
+
+Both pokes persist untouched, and nothing recomputes `+16`. If the phase-1
+condition were polling `unit_state` on these squadrons each frame, one of these
+writes should have provoked *something*. The consistent reading is that the
+polls at `0xF524` live in a coroutine that **only runs when a trigger starts
+it** (built-in 1 `start_coroutine`, fed from the queue at `[phase+272]`), so
+changing unit state without firing the trigger changes data nobody is reading.
+
+### 🔴 The gap in this method: no positive control
+
+Two pokes have now produced no observable effect, and **I cannot distinguish
+"the game ignored the write" from "the write never reached the game"**. The
+stick test only proves the value persisted *in the shared-memory file* — it does
+not prove Canary's guest sees it.
+
+That is a real hole, and it should have been closed before drawing conclusions
+from a null result. **The control to run first: poke something with a visible
+effect** — the player's hull, or a HUD counter — and confirm the change appears
+on screen. Until that passes, every "poking X did nothing" here is unfalsifiable
+rather than informative, and the two null results above must be read as
+*inconclusive*, not as evidence about the condition.
+
+**What still stands** from these runs is only what was *observed*, not poked:
+the arrival transitions, the destruction of ADN111, and the mission-over branch.