The clean re-run after the harness fixes. Three numbers have now been attached
to this question and the first two were both about the tool:

    #112 said        14   (a baseline taken during the mute migration)
    pre-fix run     128   (the column-0 `$` artifact, ~49 of them fake)
    clean run        79 BROKEN + 30 CRASH, out of 799 files

And 799 is the wrong denominator too. Split by scope:

    OPAL setlist        13 files    0 BROKEN   0 CRASH
    live/              694 files   51 BROKEN  21 CRASH   ~10%
    study/              59 files   13 BROKEN   3 CRASH
    sandbox/blocks/test 21 files    5 BROKEN   3 CRASH

`study/` is Tidal DOCUMENTATION with inline examples — prose that was never
meant to compile as a track. Counting it inflates the figure the same way the
harness bug did, just more quietly. The number worth quoting is 51+21 of 694.

THE GIG IS UNAFFECTED. Zero setlist tracks in either category, and gig-up is GO.

The CRASH class is new and it is the valuable one. These tracks COMPILE, then
throw when queried — invalid mini-notation inside a string, which is exactly why
the type checker waved them through:

    "[d d] <d d d*2 d*4>]"     unbalanced bracket
    "~ ulgab?:1"               `?` before `:`
    "[0 .. 7 0]"               a range with a trailing element
    "<0.75 .. 0.8 0.8 .. 0.65>"  a sequence on the left of `..`

Every one would fail live, because the scheduler queries every cycle. Until this
run they were all reported as "FAIL — 0 orbit(s) SILENT".

Deliberately NOT fixed here. None are in the set, and each one needs a decision
about what PLN meant — "[0 .. 7 0]" has at least two readings and only he knows
which. Triage is the deliverable; the edits are his call.

Also records a counting caveat rather than hiding it: silent-eval prints a
track's STEM, not its path, so stems that exist in several directories are
marked as ambiguous instead of guessed. The real fix is repo-relative paths in
silent-eval's output — noted on #112, not silently papered over.