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**;