re: the wave timetable's t is SECONDS, measured against the live speed law

Route keyframes are (time, quat x4, pos x3), so each consecutive pair gives an
implied speed. The flight-speed law was measured live against a real-time clock
(cruise ~420, max ~1530 world units/s), which makes it an independent yardstick
in known units.

Across all 28 stage tables, 331 Route_* records and 1104 keyframe pairs: under
SECONDS not one pair exceeds the 1530 ceiling (median 147); under frames at 30
or 60 fps, 89% and 94% of the game's routes would demand impossible speeds.

Two corrections recorded. A first pass silently skipped non-numeric fields while
flattening records, shifting every later value -- it reported a median implied
speed of 65534, suspiciously 2^16, which is what exposed it. And the remaining
outliers were Frame_S<NN>_Asteroid records, not routes; the final measurement
filters by record kind rather than dropping whole stages.

docs/re/BACKLOG.md

@@ -395,7 +395,10 @@ search cannot find a *schedule*.
   🟡 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.
+  ✅ **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
+  frames at 30/60 fps. See [`mission-wave-arrivals.md`](mission-wave-arrivals.md).
 * ✅🟡 **Motion-independent liveness probe works; `n` is probably craft-per-member**
   (2026-08-24) — [`mission-liveness-probe.md`](mission-liveness-probe.md).
   Enumerating by definition pointer instead of by motion removes the ±10 noise