re: fix the wrong ISL conditions -- the cause was a coroutine boundary, not the filter

The listing showed end_coroutine as the left-hand side of 34 comparisons disc-wide.
That is impossible -- it returns no value a script can test -- so it was the bug
reporting itself.

The recorded fix ("set special[0] only for built-ins that write [phase+164]") is
REFUTED.  end_coroutine's handler 0x82272624 is `addi r11,r0,1 ; addi r3,r0,3 ;
stw r11,164(r31)` -- it DOES write [phase+164], so that filter would have kept it.
Reading the handler before writing the filter is what caught this.

The real cause: end_coroutine returns 3, which DESTROYS the thread.  Execution does
not continue past it, so the instructions following it in the flat stream belong to
a different routine and every tracked value is stale.  The linear walk that makes
the decode possible is exactly what walks across that boundary.

A/B over all 28 stages, 7563 sites, resetting the tracker at end_coroutine:
  sites whose operands change            34  (0.45%)
  LHS = end_coroutine, before -> after   34 -> 0
  left as an explicit unknown            34  (0.45%)

The two counts being equal is the result: the leak was confined to exactly the sites
that displayed the impossible value, so the other 7529 conditions were never
affected.  Those 34 now print "<unknown: reached after a coroutine boundary>".

Not done, and said so: their RHS is still exact and the LHS is recoverable by seeding
the tracker at coroutine entries, whose targets are staged slot 0 of start_coroutine.

data/isl-stage02-conditions.txt regenerated; calls and phase-ends both byte-identical.

docs/re/BACKLOG.md

@@ -1425,10 +1425,18 @@ premise was wrong.**
   `data/isl-stage02-conditions.txt` finally has a generator
   (`isl_report.py conditions`); the other two artefacts regenerate identical.
   Top predicates: `hp_pct_test` 1955, `unit_state` 1257, `unit_relation` 796,
-  `dist_lt` 450. 🟡 **1.6 % are WRONG:** 15 sites attribute the LHS to
-  `end_coroutine`, which returns nothing — the tracker sets `special[0]` on every
-  call, so those show a stale value. Fix = only set it for built-ins that write
-  `[phase+164]`. ▶️ **Still open:** the 35 unnamed built-ins (`builtin16` 132
+  `dist_lt` 450. ~~🟡 **1.6 % are WRONG:** 15 sites attribute the LHS to
+  `end_coroutine`… Fix = only set it for built-ins that write `[phase+164]`.~~
+  ✅ **(2026-08-27) FIXED, and that proposed fix was REFUTED** — `end_coroutine`'s
+  handler `0x82272624` *does* `stw r11,164(r31)`, so the filter would have kept
+  it. Real cause: `end_coroutine` returns **3 = destroy the thread**, so the flat
+  stream continues into a DIFFERENT routine and the tracked state is stale. A/B
+  over 28 stages: exactly **34 of 7563** sites change, **34 → 0** with an
+  `end_coroutine` LHS, and the two counts being equal proves the leak was
+  confined to them — the other 7529 were never affected. They now print an
+  explicit unknown. 🟡 Recoverable but not recovered: the RHS of each is still
+  exact, and seeding the tracker at coroutine ENTRIES (`start_coroutine`'s target
+  is staged slot 0) would resolve the LHS. ▶️ **Still open:** the 35 unnamed built-ins (`builtin16` 132
   sites, `builtin105` 117, `builtin103` 115 — each now a vtable-slot lookup);
   which condition guards each `END_PHASE` (needs the control flow between them);
   the vtable's length. The condition lives in the `op10`/`op13` poll loop upstream of