re: long run — a squadron ground 18 to 2, still no arrival

The per-record instrument works and resolves individual squadrons. Over 240 s
with the hunting pilot, seven loss events all landed on the same record,
tracking one e007 Turret squadron from 18 craft down to 2 while deployed held at
41 and the global count fell 300 to 284. Losses come in steps of 2 after an
opening drop of 4, which is unexplained and recorded rather than smoothed over.

This weakens the frame-rate explanation from the previous iteration. At ~16.5
fps against a 30 Hz tick, game time runs at about 55 % of wall-clock, so route
entries t = 90 and t = 120 land near 163 s and 218 s wall. The run reached 234 s
wall, roughly 129 game-seconds, passing both, and no arrival occurred at either.
"The runs were too short" no longer covers t = 90 and t = 120, though it still
covers 170, 210 and 240 -- the run was cut at 240 s by the turn timeout rather
than the planned 330 s, so t = 170 was never reached.

It also sharpens the event-gated model into something testable. The squadron
ended at 2, not 0, and no squadron has been eliminated in any run so far. If the
trigger is a squadron being wiped out rather than merely damaged, every
observation to date is explained: seven kills produced no arrival because they
never finished anything off.

Next is the cheapest decisive experiment yet available: run 60-90 s longer so
that squadron reaches zero and watch for a 0 -> n in the following samples. The
~210 s title movie at boot remains the binding constraint, leaving about 350 s of
observation per turn.

docs/re/BACKLOG.md

@@ -366,9 +366,16 @@ search cannot find a *schedule*.
   **16.5/s**, which is the emulator's known ~14–19 fps. 🟡 New leading
   explanation: **the runs were far too short in GAME time** — at ~55% of
   wall-clock, the longest 240 s run reached only t≈132, past the t=90/120 route
-  entries but nowhere near t=170/210/240. **Next: one long run** (~350 s probe)
-  watching for `0→n` near t≈163 s and 218 s wall. If still nothing, the
-  frame-rate explanation is refuted and event-gating returns as front-runner.
+  entries but nowhere near t=170/210/240. ✅🔴 **Long run done (2026-08-24)**: per-record tracking
+  works — watched ONE turret squadron fall **18→14→12→10→8→6→4→2** over seven
+  loss events while `deployed` held at 41. 🔴 **Still no arrival at 234 s wall
+  (≈129 game-s), past both t=90 and t=120**, so the "too short" explanation no
+  longer covers those (it still covers t=170/210/240; the run was cut at 240 s by
+  the turn timeout, not the planned 330 s). 🟡 **Sharper hypothesis:** the
+  squadron ended at **2, never 0** — no squadron has ever been eliminated in any
+  run, so the trigger may be *elimination*, not damage. **Next: run ~60–90 s
+  longer so that squadron reaches 0, and watch for `0→n`** — a direct test of the
+  event-gated model.
   ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
   time per turn.
   Earlier framing: