re: the unreached code -- five mechanisms eliminated, nothing in the file names it

Inverting the question -- read what an unreached routine DOES, rather than testing
another candidate mechanism -- sharpened this a lot without solving it.

The metric was partly inflated.  Of 24901 unreached instructions in 564 runs, 458 runs
are length 1, and 111 of those are a lone `ret` stranded after an end_coroutine, with
the next routine being a properly seeded entry.  Stage 02's first two "unreached
routines" are exactly that.  But those are only 458 instructions: the real gap is
24443 in 106 runs, the largest 1526 (Stage 26), 1496 and 1481 (Stage 29), 1069, 904.

And it is live mission logic.  Stage 26's 1526-instruction run stages arguments and
calls builtin57(ADN110, 1) and set_group_speed(ADN110, 2, 0) -- named units, named
built-ins.

New this iteration: kill_coroutine (built-in 5) is confirmed as a code-offset carrier,
which is what the corpus said -- its local[0] resolves 150/150 onto the instruction
stream against a 34.0% control, values 13740..221048.  And, like the others, it points
at zero unreached run-starts.

That is now five mechanisms.  Across 2757 code references -- start_coroutine 1765, the
phase timeline 675, built-in 19's trigger handlers 79, kill_coroutine 150, and the
0x1883 records 88 -- not ONE lands on an unreached run-start.  A categorical absence,
not a near miss.

Not a tool artefact: 1765 of 1765 start_coroutine sites resolve with 0 missed, 0
entries land outside their phase region, and 0 are discarded by the on-stream filter.

Combined with the earlier result that an unreached routine's offset appears nowhere in
the file as a word in any encoding, these routines are referenced by nothing inside the
.ssb.  Either they are unused in this build, or they are entered from outside it.  A
1526-instruction routine driving a named squadron sits badly with "unused", but that
discomfort is not evidence and the two readings are recorded without choosing.

No static test I have devised can decide it; a runtime probe logging sub_822737C8's
third argument through a mission would.

All artefacts regenerate byte-identical; documentation only.

docs/re/BACKLOG.md

@@ -135,6 +135,24 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   🟡 **Still does not explain the unreached code** — 0 of the 79 handler offsets are
   unreached run-starts.
 
+* 🟡 **(2026-08-27) THE UNREACHED CODE — five mechanisms eliminated, nothing in the
+  file names it. [isl-unreached-code](isl-unreached-code.md).** Inverting the question
+  (read what an unreached routine DOES) sharpened it. **Metric partly inflated:** of
+  24901 unreached instructions in 564 runs, **458 are length-1** (111 a lone `ret`
+  stranded after `end_coroutine`) — but the gap is real: **24443 instructions in 106
+  runs**, up to **1526** long. It is live logic: Stage 26's biggest run calls
+  `builtin57(ADN110,1)` and `set_group_speed(ADN110,2,0)`. 🔑 **NEW: `kill_coroutine`
+  (built-in 5) confirmed as a code-offset carrier — 150/150 on-stream vs a 34.0 %
+  control** — yet **0 unreached run-starts**, the fifth such result. Across **2757
+  code references** from five mechanisms (`start_coroutine` 1765, timeline 675,
+  built-in 19 triggers 79, `kill_coroutine` 150, `0x1883` 88), **not ONE lands on an
+  unreached run-start.** ✅ Not a tool artefact: 1765/1765 `start_coroutine` entries
+  resolve, 0 outside a phase region, 0 dropped by the on-stream filter. 🟡 With the
+  earlier "the offset appears nowhere as a word in any encoding", these routines are
+  referenced by **nothing inside the `.ssb`** — either unused in this build, or
+  entered from outside it. ▶️ **No static test I have devised can choose**; a runtime
+  probe on `sub_822737C8`'s third argument would.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the