re: find the arrival timetable; refute the entity-count proxy for waves

The routes' first-keyframe time is the arrival schedule. It is not always zero,
and grouping Stage 02's 120 route records by phase and first-frame time gives a
timetable: phase 1 releases 25 routes at t=0 then 3, 3, 3, 2, 1 at t = 90, 120,
170, 210, 240. Phase 2 has every one of its 37 routes at t=0, which is what
pins the meaning: t is measured from the start of its phase, not of the mission.
Entering a phase releases that phase's t=0 group and the rest follow on the
offsets.

That completes the data side of the question this line of work started from --
the schedule is data, split across UnitGroup (who) and Route (when, and the path
flown in), with no fixed enemy count anywhere.

Refuted: counting spawned-entity records does not reveal arrivals. One Stage 02
flight, 210 s sampled every 15 s, counting aligned 0x820af030 in an 8.3 MB span:
flat at 116 throughout, no step at 90, 120, 170, 210 or anywhere.

The reason looks more useful than the refutation. UnitGroup_S02's Count fields
sum to exactly 116 members, and there are exactly 116 records from the first
sample on, so the game most likely allocates one record per roster member at
mission load and a route arrival activates an existing record rather than
creating one. Kept at 🟡, not promoted: n=1, and the obvious refutation -- check
another stage's record count against its member sum (S01=42, S16=2, S29=95) --
needs a save for another stage, and only slot 01 / Stage 02 exists. Noted as the
blocker rather than worked around.

Not settled: whether the timetable's t is frames or seconds (at 30 Hz t=240 is
8 s; as seconds it is 4 min), and where an arrival is observable in memory. The
live flag is presumably a field inside those 116 records, which is a well-scoped
next probe now that the record set is bounded and located.

Operational note recorded: cold boot spent 204 s in the title movie, so a 300 s
probe overran the turn and the first attempt died with its output still in the
pipe. Log to a file rather than piping to tail.

docs/re/BACKLOG.md

@@ -310,6 +310,16 @@ search cannot find a *schedule*.
   and 14 manoeuvre weights per profile). 🔴 Refuted: the 8-value frame is *not*
   universal — `Formation_Fleet_01/02` use 136 and 4 values per frame.
 
+* ✅🔴 **The arrival timetable is found; the entity-count proxy is refuted**
+  (2026-08-24) — [`mission-wave-arrivals.md`](mission-wave-arrivals.md). Route
+  records' first-keyframe time is the **arrival schedule**, measured from the
+  start of that route's *phase* (phase 2 has all 37 routes at t=0). Stage 02
+  phase 1: 25 at t=0, then 3/3/3/2/1 at t=90/120/170/210/240. 🔴 A live count of
+  `0x820af030` entity records is FLAT at 116 for 210 s — no arrivals visible.
+  🟡 116 is exactly Stage 02's roster member count, suggesting one pre-allocated
+  record per member (n=1, NOT promoted; the refutation needs another stage's
+  save, which we do not have — only slot 01 / Stage 02 exists).
+  ❔ Still unmeasured: whether the timetable's `t` is frames or seconds.
 * 🔴 **Probed 2026-08-24 and refuted the cheap hypothesis** — the phase state is
   NOT adjacent to the loaded table strings; see
   [`mission-phase-runtime.md`](mission-phase-runtime.md). The run did confirm