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/structures/isl-conditions.md

@@ -69,18 +69,54 @@ And they read as conditions:
 `dist_lt(ADT308, TCN000, 15000)` — with the world unit established as 1 metre,
 that is a **15 km** proximity test.
 
-## 🟡 A caveat the numbers themselves expose
+## ✅ FIXED — and the cause was not what I expected
 
-15 of Stage 02's 965 sites (1.6 %) attribute the left-hand side to
-**`end_coroutine`**, which does not return a value. The tracker sets
-`special[0]` on *every* call, so where the right-hand side of a comparison was
-not actually a value-producing built-in, the LHS shown is a **stale**
-`special[0]` from an earlier call. Those sites are wrong, not merely imprecise.
+The first version of this listing showed **`end_coroutine`** as the left-hand
+side of 34 comparisons disc-wide (15 in Stage 02). That is impossible —
+`end_coroutine` returns no value a script can test — and an impossible output is
+the bug reporting itself.
 
-The fix is to set `special[0]` only for built-ins that write `[phase+164]` —
-which [`isl-builtin-dispatch`](isl-builtin-dispatch.md) makes checkable, since
-112 of 147 are vtable slots whose implementations can be tested for that store.
-Not done; recorded so the 1.6 % is not read as accurate.
+### 🔴 The obvious fix is REFUTED
+
+The plan recorded here was *"set `special[0]` only for built-ins that write
+`[phase+164]`"*. That would not have worked: `end_coroutine`'s handler
+`0x82272624` is
+
+```
+addi r11, r0, 1
+addi r3,  r0, 3
+stw  r11, 164(r31)    ; it DOES write [phase+164]
+```
+
+so the filter would have kept it. Checking the handler before writing the filter
+is what caught this.
+
+### ✅ The real cause: a coroutine boundary
+
+`end_coroutine` returns **3**, which *destroys the thread*. Execution does not
+continue past it — so the instructions that follow it in the **flat** stream
+belong to a **different routine**, and every value the tracker was carrying is
+stale. The linear walk that makes this decode possible at all is precisely what
+walks across that boundary.
+
+Resetting the tracker at `end_coroutine`:
+
+| A/B over all 28 stages, 7563 sites | |
+|---|---|
+| sites whose operands change | **34 — 0.45 %** |
+| LHS `end_coroutine` before → after | **34 → 0** |
+| left as an explicit unknown afterwards | **34 — 0.45 %** |
+
+**The two counts are equal, so the leak was confined to exactly the sites that
+displayed the impossible value** — the other 7 529 conditions were never
+affected. Those 34 now print
+`<unknown: reached after a coroutine boundary>` rather than a wrong answer.
+
+🟡 **They are recoverable but not recovered.** The right-hand side of each is
+still exact; only the left is lost. Resolving them means seeding the tracker at
+each coroutine **entry** rather than walking in from the previous routine, and
+the entries are available — `start_coroutine`'s target is staged slot 0. Not
+done.
 
 ## 🟡 Not settled