re: the mission script is resident immediately -- two explanations refuted

ssb_watch.py polls the .ssb header, a symbol string and find_mission from the
moment flight is detected. On a normal run all three are present at the FIRST
sample (t=0.0, mission 0xBC79C960), so 'the script loads later than assumed' and
'the probe raced a load' are both out -- there is no window in which a healthy
mission flies without its script in memory.

A detail worth more than it looks: at that sample screen_id reported 'other',
not 'flight'. The script is loaded and the ScriptMission locatable BEFORE the
flight HUD appears, so residency is not gated on the HUD, and a run showing the
HUD without the script is in a state a healthy run never passes through.

That leaves the third candidate: the anomalous run's mission never loaded and
its IN FLIGHT was a misdetection -- consistent with it being frozen on a black
screen when checked afterwards. Not proven, but now the only surviving
explanation rather than one of three.

docs/re/script-runtime-probe.md

@@ -447,7 +447,32 @@ is not — in a mission that is demonstrably flying. That contradicts four earli
 runs where the header was found within seconds of flight.
 
 **I do not have an explanation**, and I am not going to invent one. Candidates
-worth separating next time: the script is loaded later than I assumed and the
-earlier runs sampled later; the probe raced a load; or this run entered flight
-by a different path. The cheap discriminator is to poll for the header from the
-moment flight starts and record *when* it appears, rather than sampling once.
+worth separating: the script is loaded later than I assumed; the probe raced a
+load; or this run entered flight by a different path.
+
+### ✅ Two of the three candidates are refuted — the script is resident IMMEDIATELY
+
+`tools/re-capture/ssb_watch.py` polls all three markers from the moment flight is
+detected. On a normal run:
+
+```
+[   0.0s] header   FIRST SEEN (1)
+[   0.0s] ADN110   FIRST SEEN (4)
+[   0.0s] mission  FIRST SEEN (1)
+[   0.0s] header=1 ADN110=4 mission=0xBC79C960
+```
+
+**All three are resident at the very first sample**, so "the script loads later
+than I assumed" and "the probe raced a load" are both **out**. There is no window
+in which a healthy mission is flying without its script in memory.
+
+🔑 And a detail that matters more than it looks: at that moment `screen_id`
+reported **`other`, not `flight`** — the script is fully loaded and the
+`ScriptMission` locatable *before* the flight HUD appears. So residency is not
+gated on the HUD, and a run showing the HUD without the script is in a state a
+healthy run never passes through.
+
+That leaves the third candidate: **the anomalous run's mission never loaded**,
+and its `IN FLIGHT` was a misdetection. Consistent with what became of it — it
+was **frozen on a black screen** when checked afterwards. Not proven, but it is
+now the only surviving explanation rather than one of three.