re: the positive control ran, and is still inconclusive

poke_control.sh (self-retrying, succeeded on attempt 1 with no freeze) set the
player's hull at pos+0x154 to 1. Twelve seconds later the game had put
0x447A0000 back.

That establishes an asymmetry worth having: the hull word is continuously
rewritten by the game, while the unit-record fields held our value untouched for
60s. It separates fields the game maintains from fields nobody writes.

But it is not yet a control. The after-frame shows a red WARNING banner -- and
the before-frame already shows MISSILE ALERT, so the ship was under attack in
both and the banner is not attributable to the poke. A value being overwritten
proves the game writes that address, not that it read ours.

Correction: hull at pos+0x154 is 0x447A0000, a FLOAT 1000.0, not the 1500 the
pilot logs -- those are different fields or scales and should not be conflated.

The settling refinement: poke in a tight loop for several seconds so the value is
low whenever the game samples it. If hull is authoritative the ship dies and the
screen goes to GAME OVER; if it survives, the field is a readout.

The reusable part is the harness: boot -> verify animating -> locate -> act, with
a freeze at any step costing one retry rather than the iteration.

docs/re/script-runtime-probe.md

@@ -322,3 +322,44 @@ rather than informative, and the two null results above must be read as
 
 **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.
+
+## 🟡 The positive control ran — and is still inconclusive
+
+`tools/re-capture/poke_control.sh` (self-retrying; **succeeded on attempt 1**, no
+freeze) poked the player's hull at `position + 0x154` to `1`, on the theory that
+the game visibly reacts to a dead player.
+
+```
+hull before: 0x447A0000        (= 1000.0f)
+poke        0x447A0000 -> 0x00000001   OK
+hull after : 0x447A0000        (12 s later -- the game put it back)
+screen before: flight     screen after: flight
+```
+
+**What it establishes:** the hull word is **continuously rewritten by the game**,
+so a poke there cannot persist — unlike the unit-record fields, which held our
+value for 60 s untouched. That asymmetry is itself informative: it separates
+fields the game actively maintains from fields nobody is writing.
+
+**Why it is still not a control.** I looked for a visible reaction and found a
+red `WARNING` banner in the after-frame — but the before-frame already shows
+`MISSILE ALERT`, i.e. the ship was under attack in both. **The banner is not
+attributable to the poke**, and I am not going to count it. A value being
+overwritten proves the game writes that address; it does not prove the game
+*read* ours.
+
+**New fact, and a correction:** hull at `pos + 0x154` reads `0x447A0000` — a
+**float, 1000.0** — not the `1500` the pilot logs. The pilot's `hull=` is a
+different field or scale, and the two should not be conflated.
+
+### The refinement that would settle it
+
+Poke in a **tight loop** for several seconds so the value is low whenever the
+game samples it, rather than once between two of its own writes. If hull is
+authoritative, the ship dies and the screen goes to `GAME OVER` — unambiguous. If
+it survives a sustained low hull, the field is a readout and the authoritative
+copy is elsewhere. Either answer is worth having.
+
+✅ **The self-retrying harness works** and is the reusable part of this
+iteration: boot → verify animating → locate → act, with a freeze at any step
+costing one retry instead of a whole iteration.