re: the flat entity count is explained -- arrivals are not spawns

Built-in 12 activate_unit returns 0 when the live object is NULL: it registers an
object that already exists and cannot create one. So a wave arrival is a craft
reaching a point on its route, not a new record, and a count of entity records
was never going to move.

Stage 02's UnitGroup totals Count = 116 across 111 squadrons, matching the live
probe's flat 116. The natural objection is that 116 might match by accident --
it does not: across all 28 stages the roster totals run 2..116, and 116 is the
MAXIMUM and unique to Stage 02, with nothing else within 5.

Three independent things agree: the handler cannot spawn, the roster totals 116,
and the live count sits at 116 while 22 of 113 routed squadrons have a route
starting after t=0.

Still n=1 for the per-member identity (only a Stage 02 save exists), and this
cannot settle timetable-vs-event -- that needs a position probe, not a count.

docs/re/BACKLOG.md

@@ -392,9 +392,13 @@ search cannot find a *schedule*.
   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).
+  ✅ **2026-08-26: the flat count is explained, not merely refuted.** Built-in 12
+  `activate_unit` returns immediately when the live object is NULL — it registers
+  an existing object and cannot spawn one, so arrivals are route positions, not
+  new records. Stage 02's roster totals 116, and **116 is the maximum across all
+  28 stages and unique to Stage 02**, so the match is not a common-number
+  coincidence. 🟡 still n=1 for the per-member identity. ❌ This cannot settle
+  timetable-vs-event — a position probe is needed, not a count.
   ✅ **Settled 2026-08-26: `t` is SECONDS.** Consecutive route keyframes give an
   implied speed; checked against the live-measured player ceiling (~1530 world
   units/s), **0 of 1 104** pairs exceed it under seconds while 89–94 % do under

docs/re/mission-wave-arrivals.md

@@ -504,3 +504,49 @@ Both are the same kind of mistake and worth recording:
 * Whether `t` is measured from **phase start** (as the arrival schedule reads it)
   or from mission start is unchanged by this — that was already settled
   separately.
+
+## ✅ The entity-count proxy was not just refuted — there was nothing to see
+
+**2026-08-26.** A live count of `0x820af030` entity records stayed **flat at 116
+for 210 s**, spanning Stage 02's scheduled arrivals at t = 90/120/170, and was
+recorded above as refuting the proxy. It is worth saying *why* it was flat,
+because the reason is now established and it is not "the proxy is broken".
+
+**Arrivals are not spawns.** Built-in 12 `activate_unit`, read from the
+disassembly (`sub_822659F0`, see
+[structures/isl-builtins.md](structures/isl-builtins.md)), **returns 0
+immediately when the live object `[record+4]` is NULL** — it registers an object
+that already exists and sets its state to *active*. It cannot create one. So the
+mission's craft are instantiated up front and a "wave arrival" is a craft
+reaching a place along its route, not a new record appearing.
+
+**The count matches the roster exactly, and the number is distinctive.**
+Stage 02's `UnitGroup` table holds **111 squadron records totalling `Count` =
+116 members** — the same 116 the live probe saw and never left. The obvious
+objection is that 116 might be an unremarkable number that matches by accident.
+It is not:
+
+    roster member totals, all 28 stages:
+      2 4 4 9 11 12 14 17 32 36 37 42 43 45 48 50 53 54 54 62 64 66 69 70 87 90 95 116
+
+**116 is the maximum across the whole game and Stage 02 is the only stage with
+it** — no other stage is within ±5. The save we have is a Stage 02 save.
+
+So three independent things line up: the handler cannot spawn, the roster totals
+116, and the live count sits at 116 and never moves while 22 of Stage 02's 113
+routed squadrons have a route beginning after t = 0.
+
+### What this does and does not settle
+
+* ✅ **Arrivals are not spawns**, and the flat count is the expected behaviour
+  rather than a failed measurement. Read from the code, not inferred.
+* 🟡 **One pre-allocated record per roster member.** Strong — the mechanism
+  explains it and the matching number is unique to this stage — but still
+  **n = 1**: only a Stage 02 save exists, so the identity has been checked on one
+  mission. The previous entry's "n=1, NOT promoted" caution still applies; what
+  has changed is that there is now a mechanism behind the number.
+* ❌ **It does not settle timetable versus event.** Knowing that craft are
+  pre-allocated says nothing about *what* starts a route — a clock or a
+  trigger. That test still needs a live run, and the entity count can never
+  perform it, because there are no spawns for it to count. A different probe is
+  required: watch a delayed squadron's **position**, not the record count.