re: deployment is resolved at mission load; withdraw the take-off hypothesis

The run meant to catch a deployment step at take-off removed the hypothesis
instead. One continuous series of 64 samples over about 380 s, started when the
roster first appeared and running through the ready room, the transition to
flight at +47 s, and several minutes of flight, shows deployed at 41 and craft
at 292 with not one change in either number.

So the previous iteration's suggestion that deployment is a single step at
take-off is withdrawn. It rested on ready room 39/276 against flight 41/300,
which came from different runs and was flagged 🟡 for that reason. Measured
within one run the values are identical before and after take-off, so that gap
was cross-run variance.

What this does establish is stronger. The roster is already deployed when the
roster first exists: 41 of 116 records hold craft before the ready room ends and
nothing changes afterwards. Together with the roster identity confirmed on two
stages and the earlier piloted runs, Stage 02 phase 1 has no observable
in-mission arrival at all -- not in the ready room, not at take-off, and not in
up to 435 s of verified-live flight during which the player destroyed 42 craft.

The route times still mean something, since 0/90/120/170/210/240 and Stage 01's
1500/1800/2100 are structured rather than noise. The frames reading remains the
best fit, and under it they are most likely fly-in animation timings applied at
load rather than release times.

Two things stay open and are recorded as such. Phases 2 and 3 have never been
tested: every run has stayed in phase 1 and phase advance was never located, so
a phase transition is now the most likely place an arrival could exist. And this
particular run had no pilot, so it adds nothing on event-gating; the piloted
435 s run already covers that ground.

docs/re/BACKLOG.md

@@ -494,6 +494,19 @@ search cannot find a *schedule*.
   at TAKE-OFF**, not a schedule unfolding in-mission (different runs, so
   suggestive only). **Next: one ~400 s run spanning ready room → take-off →
   flight** to catch the 39→41 step in one continuous series.
+* ✅🔴 **(2026-08-24) DEPLOYMENT IS RESOLVED AT MISSION LOAD.** One continuous
+  series, 64 samples over ~380 s from roster-appearance through the ready room,
+  take-off (`IN FLIGHT` at +47 s) and flight: **`deployed=41, craft=292`, zero
+  changes throughout.** 🔴 **My own "deployment happens at take-off" is withdrawn**
+  — the 39/276 vs 41/300 gap was cross-run variance; within one run there is no
+  step. ⇒ **Stage 02 phase 1 has NO observable in-mission arrival**: 41 of 116
+  records are deployed before the ready room ends, and nothing changes in the
+  ready room, at take-off, or in up to 435 s of verified-live flight with 42
+  kills. Route times most likely encode **fly-in animation timing applied at
+  load**, not release times (frames reading: S01's t=2100 → 70 s at 30 Hz).
+  ❔ **Phases 2 and 3 are entirely untested** — every run has stayed in phase 1,
+  and phase advance was never located; a phase transition is now the most likely
+  place an arrival could exist.
   🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
   most kills, so pilot polling is not the throttle.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;

docs/re/mission-arrival-watch.md

@@ -612,3 +612,57 @@ unfolding during the mission.
 **Next:** one run with the probe waiting for the roster and sampling for ~400 s,
 long enough to span ready room → take-off → flight in a single continuous
 series. That would show the 39 → 41 step directly, or refute it.
+
+---
+
+# ✅ Deployment is resolved at mission LOAD (2026-08-24)
+
+The run that was supposed to catch a take-off step instead removed the
+hypothesis. One continuous series, 64 samples over ~380 s, started when the
+roster appeared and running through the ready room, take-off (`IN FLIGHT` at
++47 s) and the whole flight:
+
+```
++    0.3s  deployed= 41  craft=292
+   … 64 samples, ZERO changes …
+last     deployed= 41  craft=292
+```
+
+**Not one change in either number**, across the ready room, the transition, and
+several minutes of flight.
+
+## 🔴 Refuted: my own "deployment happens at take-off"
+
+The previous entry noted ready room 39/276 against flight 41/300 and suggested
+deployment was a single step at take-off, flagged 🟡 because the numbers came
+from *different runs*. Measured within one run, there is no step: the values are
+identical before and after take-off. **That was cross-run variance and the
+hypothesis is withdrawn.**
+
+## What this establishes
+
+**The roster is already deployed when the roster first exists** — 41 of 116
+records hold craft before the ready room ends, and nothing changes afterwards.
+Combined with everything else in this file:
+
+* every participant is allocated at mission load (roster identity, two stages);
+* 41 of 116 records are deployed from the first observable instant;
+* no `0 → n` transition occurs in the ready room, at take-off, or in up to 435 s
+  of verified-live flight with 42 kills.
+
+So **Stage 02 phase 1 has no observable in-mission arrival at all.** Whatever the
+route table's first-keyframe times do, they do not release squadrons on a clock
+that this instrumentation can see, and they do not respond to the player
+destroying 42 craft.
+
+## What remains open
+
+* The route times still mean *something* — the values 0/90/120/170/210/240 and
+  S01's 1500/1800/2100 are structured, not noise. The frames reading
+  (t = 2100 → 70 s at 30 Hz) remains the best fit, in which case they are most
+  likely **fly-in animation timings applied at load**, not release times.
+* Phases 2 and 3 are entirely untested. Every run has stayed in phase 1, and
+  phase advance was never located. If arrivals exist, a phase transition is the
+  most likely place to see one.
+* This run had **no pilot**, so it says nothing new about event-gating; the
+  piloted 435 s run already covers that.