re: entry_a is a code/data boundary, not an entry -- and the decoder was reading data as code

Disassembling the three Stage-02 entry_a targets shows opcodes 0x19 and 0x1A, and the
ISL dispatcher's table has 25 entries (cmplwi 0x18).  They are not instructions.  Each
phase region ENDS with a trailing data table of 8-byte typed records -- tag 0x19 = int,
tag 0x1A = IEEE float (0.0, 0.5, 1.0, 4.0) -- and entry_a is where it starts.

Confirmed across the disc: in 44 of 44 phases the first offset whose opcode exceeds
0x18 is exactly that phase's entry_a, with zero exceptions, and only two tags ever
appear (1394 x 0x19, 675 x 0x1A).  So the record is

    0x1883, base, size, 0, code_end, force_end_handler

one boundary and one entry, not two entries as the previous commit said.

That also retires this thread's own "82 of 88 land on a valid instruction = 93.2% vs a
38.6% control" as TOO WEAK a test: a data record has length 8 and passes "nonzero,
even".  The entry_b result stands on different evidence -- those targets were matched
against isl.call_sites(), an independent enumeration.

isl.linear_offsets was decoding all 2069 data records as instructions, 1.23% of the
stream.  Now each phase's walk stops at its boundary:

  decoded instructions   168251 -> 166182  (= 168251 - 2069, as predicted)
  opcode > 0x18               2069 -> 0
  call sites covered     25705/25705 -> 25705/25705
  exits unreachable                0 -> 0
  conditions unknown             400 -> 400

Recorded because the first attempt at the fix was worse than the bug: it destroyed 36%
of the stream (168251 -> 107596, exits 0 -> 74) because linear_offsets is ONE global
walk from the first phase base, so stopping at phase 1's table lost every later phase.
It has to skip the region and resume at the next base.  A count moving hard in the
wrong direction is the same signal as one that will not move.

Still open: the table's contents are undecoded -- its int values land on the
instruction stream 46/51 against a 29.5% chance rate, but 0 of them are unreached
run-starts, so this is not what starts the unreachable code either.

docs/re/BACKLOG.md

@@ -35,8 +35,22 @@ unknown, what evidence exists, and what the first step would be. Move an item in
   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.
+  ✅ **(2026-08-27) `entry_a` IDENTIFIED — and it is NOT an entry point.** It is the
+  offset where the phase's CODE ends and a trailing **DATA table** begins: 8-byte
+  typed records, tag `0x19` = int, tag `0x1A` = IEEE float, and the dispatcher only
+  has 25 opcodes (`cmplwi 0x18`). **44 of 44 phases: the first opcode > 0x18 is
+  exactly `entry_a`, zero exceptions**; only tags 0x19 (1394) and 0x1A (675) occur.
+  So the record is `0x1883, base, size, 0, code_end, force_end_handler`. ⚠️ This
+  also retires the earlier "93.2 % land on a valid instruction" test as TOO WEAK — a
+  data record has length 8 and passes "nonzero, even". 🔧 `isl.linear_offsets` was
+  decoding all **2069** data records as instructions (1.23 %); now stops per phase
+  at the boundary: **168251 → 166182**, op>0x18 **2069 → 0**, call-site coverage
+  held at **25705/25705**, exits still 0 unreachable, conditions unchanged at 400.
+  ⚠️ The first attempt at that fix cost **36 %** of the stream (168251→107596,
+  exits 0→74) because the walk is global and stopped at phase 1's table — it must
+  SKIP and resume per phase. 🟡 Still open: the table's contents are undecoded (its
+  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.
 
 ## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)