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.

tools/re-capture/isl.py

@@ -254,13 +254,36 @@ def linear_offsets(b, start=None):
     reaching a call site needs no control-flow reconstruction at all.
     """
     end = struct.unpack_from('>I', b, 0x0C)[0]          # symtab1 = end of code
-    if start is None:
-        start = phase_bases(b)[0]
+    # Walk EACH PHASE separately: a phase's code runs from its base up to that
+    # phase's trailing data table, and the next phase's code begins at its own
+    # base.  A single global walk stops dead at phase 1's table and loses every
+    # later phase -- that mistake cost 36% of the instruction stream.
+    bases = phase_bases(b)
+    if start is None or start in bases:
+        out = []
+        limits = list(bases[1:]) + [end]
+        for base, hi in zip(bases, limits):
+            out.extend(_walk_one(b, base, hi))
+        return out
+    return _walk_one(b, start, end)
+
+
+def _walk_one(b, start, end):
     out = []
     off = start
     while off + 4 <= end:
+        w = struct.unpack_from('>I', b, off)[0]
+        # The dispatcher's table has 25 entries (`cmplwi 0x18`), so an opcode
+        # above 0x18 is NOT an instruction.  Each phase region ends with a
+        # trailing DATA table of 8-byte typed records -- tag 0x19 = int,
+        # tag 0x1A = IEEE float -- and its start is the FIRST entry of that
+        # phase's mission-level `0x1883` record.  Measured: in 44 of 44 phases
+        # across all 28 stages the first opcode > 0x18 is exactly that value.
+        # Decoding those 2069 records as instructions was 1.23% of the stream.
+        if (w & 0xFF) > 0x18:
+            break
         out.append(off)
-        ln = (struct.unpack_from('>I', b, off)[0] >> 8) & 0xFF
+        ln = (w >> 8) & 0xFF
         if ln == 0 or ln % 2:
             break
         off += ln