re: the trailing data table is a per-phase TIMELINE of scheduled routines

Decodes the table found at the end of every phase region.  Layout:

    int  N
    N x [ int offset ; float t ; int kind ]      -- 8-byte typed records,
                                                    tag 0x19 int, 0x1A float

1 + 3N matches the record count in every phase measured (Stage 02: 76/40/55
records for N = 25/13/18).

Checks, all independent of each other:
  schedule entries disc-wide                675
  0x1A float records disc-wide              675   (counted by a different route)
  offsets landing on the instruction stream 675/675 = 100.0%
  control, random 4-aligned offsets                  33.3%

The floats are seconds -- 0, 0.5, 1, 4, 5, 30, 50, 60, 90, 120, 150, 170, 180, 210,
240, 270, 300, 330, 360, 420, 570, 1020, 1080, 1140, 1170 -- and the targets are small
one-shot coroutines that set arguments, call one built-in and end_coroutine.  kind is
0 (556) or 5 (119) and is not identified.

Runtime cross-check, recorded as consistency rather than confirmation: the closed
REMAINING OB work measured Stage 02's squadron arrivals at t = 0, 120 and 210 s over
n=5 emulator runs, and all three appear in phase 1's static schedule, with 120 and 210
each appearing TWICE.  These are round numbers and phase 1 has ~22 distinct times over
0-1170, so presence alone is not unlikely; the doubling is the sharper detail and was
not predicted in advance.

New artefacts data/isl-stage02-schedule.txt and data/isl-schedule-all.txt with a
committed generator (isl_report.py schedule).  calls, phase-ends, conditions and
phase-guards all regenerate byte-identical.

Not settled and said so: kind is unread; the consumer is unread, so the decode rests
on the structural checks above; whether the clock is per-phase or per-mission is an
inference from the layout; and this is NOT what starts the unreachable code -- 0 of
the 675 targets are unreached run-starts, so that ~15% gap stands.

docs/re/BACKLOG.md

@@ -52,6 +52,23 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   int values hit the stream 46/51 vs 29.5 % chance but **0 are unreached
   run-starts**), and what starts the other ~15 % of code is still unknown.
 
+* ✅ **(2026-08-27) THE TRAILING DATA TABLE IS A TIMELINE — [structures/isl-schedule](structures/isl-schedule.md).**
+  Layout `int N; N x [int offset; float t; int kind]`; `1 + 3N` matches the record
+  count in every phase. **675 entries disc-wide — exactly the independently counted
+  number of `0x1A` float records — and 675/675 offsets land on the instruction
+  stream vs a 33.3 % control.** The floats are SECONDS (0, 0.5, 1, 4, 30, 60, 90,
+  120, 150, 180, 210, 240, 300, 420, 1020 …) and the targets are small one-shot
+  coroutines (`set args; call builtinN; end_coroutine`). `kind` is 0 (556) or 5
+  (119) — unidentified. 🟡 **Runtime cross-check, consistent not conclusive:** the
+  closed `REMAINING OB` work measured Stage 02 arrivals at **t = 0, 120, 210 s**
+  (n=5 emulator runs); all three are in phase 1's static schedule and **120 and 210
+  each appear TWICE** — but the times are round numbers, so presence alone is weak;
+  the doubling is the sharper detail. Artefacts `data/isl-stage02-schedule.txt` and
+  `data/isl-schedule-all.txt`; the four earlier artefacts regenerate byte-identical.
+  🟡 **Still NOT what starts the unreachable code** — 0 of the 675 targets are
+  unreached run-starts, so the ~15 % gap stands. The consumer is unread, and whether
+  the clock is per-phase or per-mission is an inference from layout, not a read.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the