re: the 0x1883 record carries entry points -- every phase exit is now reachable

data/isl-phase-guards-all.txt goes from 5 of 177 unreachable exits to 0.

The cheap first step failed, usefully.  An unreached routine's entry offset does NOT
appear as a word anywhere in the file, in any encoding: phase-relative 6.6% against an
11.5% control on reached offsets, absolute 1.6% vs 3.3%, and the /4 forms 0-1.6% vs
6.6-8.2%.  Every variant is at or below its control, which rules out the whole family
of "some instruction operand points at them".  It also rules out dead code: Stage 02's
3069 unreached instructions contain 485 calls, including start_coroutine x75,
squadron_attack x59, set_group_speed x42 and objective_marker x13.

The answer is the mission-level stream that isl-bytecode.md already partly read.  Each
0x1883 record is

    0x1883, base_delta, size, 0, entry_a, entry_b     ; entries PHASE-RELATIVE

Measured over all 28 stages, 82 of those 88 values land on a valid instruction --
93.2%, against a 38.6% chance rate for a random 4-aligned offset.  In Stage 02
entry_b is the phase's force-end handler: 0x1482C, 0x249F0 and 0x34A10, two of which
were exactly the unreachable exits, and the third being already reachable is the
consistency check.

Seeding them: exits unreachable 5 -> 0.  Those exits now report 0 necessary
conditions, which is what an engine-entered abort handler should look like.

Recorded because it is the same mistake twice: the first seeding attempt moved NOTHING
(reach 85.0% -> 85.0%, exits 5 -> 5).  dominating_conditions() builds its own entry set
and did not use the one I had patched -- fix-the-instance-not-the-class again, caught
only because an unchanged count is by now a standing signal.

Not settled and stated: reach went only 85.0% -> 85.2%, so what starts the other ~15%
of code is still unknown, and the negative above says it is not an operand in the file;
entry_a is unidentified; 6 of the 88 values do not land on an instruction.

docs/re/BACKLOG.md

@@ -20,6 +20,24 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   what starts the 389 unreachable routines is **still open**. 🟡 A trigger node's
   layout and its consumer are unread; built-in 25 stays unnamed.
 
+* ✅ **(2026-08-27) EVERY PHASE EXIT IS NOW REACHABLE — [isl-stream-entry-points](isl-stream-entry-points.md).**
+  `data/isl-phase-guards-all.txt`: **5 of 177 unreachable exits → 0.** The cheap
+  first step FAILED usefully: an unreached routine's entry offset does **not**
+  appear as a word in the file in any encoding (phase-relative 6.6 % vs an 11.5 %
+  control; absolute 1.6 % vs 3.3 %; /4 forms 0–1.6 % vs 6.6–8.2 %) — all at or
+  below chance, ruling out "some operand points at them". Nor is it dead code: the
+  3069 unreached instructions in Stage 02 hold **485 calls** (`start_coroutine` ×75,
+  `squadron_attack` ×59, `objective_marker` ×13). ✅ The answer is the mission-level
+  stream: each `0x1883` record is `0x1883, base, size, 0, entry_a, entry_b` with the
+  entries **phase-relative** — **82 of 88 land on a valid instruction (93.2 %) vs a
+  38.6 % control** — and `entry_b` is the phase's FORCE_END_PHASE handler (Stage 02:
+  `0x1482C`, `0x249F0`, `0x34A10`). Those exits now show **0 necessary conditions**,
+  which is what an engine-entered abort handler should look like.
+  ⚠️ First seeding attempt moved NOTHING (85.0 %→85.0 %, 5→5) because
+  `dominating_conditions()` builds its own entry set — fix-the-instance again.
+  🟡 Still open: reach only 85.0 %→**85.2 %**, so what starts the other ~15 % is
+  unknown; `entry_a` is unidentified; 6 of 88 values do not land on an instruction.
+
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
 
 `XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the