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/structures/isl-schedule.md

@@ -0,0 +1,76 @@
+# ✅ Each phase carries a TIMELINE — 675 scheduled routines across the disc
+
+The trailing data table found at the end of every phase region
+([isl-stream-entry-points](../isl-stream-entry-points.md)) is decoded. It is the
+mission's **scripted event schedule**.
+
+## Layout
+
+After the phase's code ends — at the first value of that phase's mission-level
+`0x1883` record — comes a run of 8-byte typed records, tag `0x19` = int,
+`0x1A` = IEEE float:
+
+```
+int   N                                     -- entry count
+N x [ int offset ; float t ; int kind ]
+```
+
+`1 + 3N` matches the record count in **every** phase measured: Stage 02's three
+phases hold 76, 40 and 55 records for N = 25, 13 and 18.
+
+## ✅ The checks
+
+| | |
+|---|---|
+| schedule entries disc-wide | **675** |
+| `0x1A` float records disc-wide | **675** — the same number, independently counted |
+| offsets landing on the instruction stream | **675 / 675 = 100.0 %** |
+| control: random 4-aligned offsets | 33.3 % |
+
+The float count and the entry count are derived by different routes and agree
+exactly, and every single offset resolves. `kind` is **0** (556) or **5** (119).
+
+## ✅ The floats are seconds
+
+The distribution is unmistakable: 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 …
+mission times, not fractions.
+
+And the targets are what a schedule would point at — small one-shot coroutines:
+
+```
+002C04:  set.i  local[0] = 1
+002C1C:  set.i  local[4] = 1
+002C34:  set.f  local[8] = 0.4
+002C50:  call   builtin106(0x1, 0x1, 0.4)
+002C5C:  call   end_coroutine
+```
+
+## 🟡 A runtime cross-check — consistent, and not proof
+
+The closed `REMAINING OB` work measured, on the emulator over n=5 runs, that
+Stage 02's squadrons arrive at **t = 0, 120 and 210 s**. All three times are in
+phase 1's static schedule, and **120 and 210 each appear twice**, which is what
+two squadrons arriving together would look like.
+
+⚠️ Stated as consistency rather than confirmation: these are round numbers, and
+phase 1 has ~22 distinct times spread over 0–1170, so three specified round
+values all being present is not by itself unlikely. The **doubling** is the
+sharper detail, and it was not predicted in advance.
+
+## Artefacts
+
+`data/isl-stage02-schedule.txt` and `data/isl-schedule-all.txt` (all 28 stages,
+675 entries), generator `isl_report.py schedule`. The four earlier artefacts
+regenerate byte-identical.
+
+## 🟡 Not settled
+
+* **`kind` (0 or 5) is not identified.** Two behaviours, no reading.
+* **This is not what starts the unreachable code.** All 675 targets are already
+  reachable — **0 are unreached run-starts** — so the ~15 % gap stands.
+* **Whether the schedule is per-phase-clock or mission-clock** is not
+  established; each phase's table restarts at t=0, which suggests per-phase, but
+  that is an inference from the layout, not a read of the consumer.
+* **The consumer is unread.** Nothing here shows the engine walking this table;
+  the decode rests on the structural checks above.