re: builtin80 is a command -- and finding that exposed an 11.75% bug in my tracker

Reading builtin80's body (0x82268460) to name it: it is NOT a predicate.  It
allocates a 20-byte object, stamps vtable 0x820A8CB0, magic 0xAB0311BA and the
unit's live object into it, pushes it onto a queue via the same helper push.i uses,
and returns 1 -- or 0 when the unit is absent.  A command.

That made the conditions listing impossible: it showed a six-way switch
`if builtin80(TCT206) == 0 … == 5` on a function returning 1 or 0.  Disassembling the
site shows two unconditional `jmp`s between the call and the compare, so 0x1B6C0 is
reached ONLY by a branch and its special[0] has nothing to do with builtin80.

op12 is unconditional -- the next instruction is never reached by fall-through -- and
the tracker walked through it exactly as it had walked through end_coroutine.  Last
iteration I fixed the instance and not the class, leaving 22x more bad sites in place
than the fix removed.

A/B over all 28 stages, 7563 sites, resetting at jmp as well:
  sites whose operands change              889  (11.75%)
  LHS unresolved, before -> after     34 (0.45%) -> 756 (10.00%)

So the previous commit's headline "0.0% unresolved" was a MISSING CHECK, not a strong
result: the linear walk always had some value to report, and reporting it was the bug.
10% is the honest figure and the other 90% is trustworthy for a reason.

Also corrected: isl-unit-args.md illustrated its diff with 0x1B6C0, which is one of
the bogus sites.  The UNIT_ARG result itself stands -- it came from reading
implementations, not from this listing -- but the example was picked from bad output.

Not done, and said so: recovering the 756 needs a dataflow join over each block's
actual predecessors, a CFG fixpoint rather than a linear pass.  The branch targets are
all known so the CFG is available; the analysis is not written.

calls and phase-ends regenerate byte-identical; conditions changes on 187 lines.

docs/re/structures/isl-unit-args.md

@@ -76,9 +76,16 @@ A 40× separation, and the additions sit exactly on the positive class.
 raw number becoming a unit name:
 
 ```
-- 0x01B6C0  if builtin80(0x8B) == 0   ->  + 0x01B6C0  if builtin80(TCT206) == 0
+- 0x01B6C0  if builtin80(1, 117) == 0   ->  + 0x01B6C0  if builtin80(TCT206) == 0
 ```
 
+⚠️ **That example was itself a bogus site** — see
+[isl-conditions](isl-conditions.md#-the-correction--i-fixed-the-instance-not-the-class).
+`0x1B6C0` is reached only by a branch, so attributing its comparison to
+`builtin80` was wrong, and `builtin80` is a command rather than a predicate. The
+UNIT_ARG result is unaffected — it was derived by reading implementations, not
+from this listing — but the illustration was picked from bad output.
+
 ## 🟡 Not settled
 
 * **The 24 are still unnamed.** Knowing an argument is a unit is not knowing what