Two lies the board was telling, both found by PLN looking at it during the column
migration. Neither had any error output anywhere; both are the rig's signature
shape, a value resolved once and never rechecked.

== 1. STALE PARSE: the board showed a file that no longer existed ==
PLN: "i see the leds red on C5 c6 not on c4 why? feels like old led convention?"

His instinct was right about staleness and wrong about the cause — it was old
DATA, not old code. The watcher followed track CHANGES only, so it held whatever
the file said the moment it was opened. Timestamps settled it in one line:

    watcher started      15:21:24
    bombe_dj.tidal        16:27:17   (the migration)

^54 existed in the 15:21 version and does not exist now. C5+C6 lit / C4 dark was
a *faithful* picture of a file 66 minutes dead. And this is livecoding — the file
changes constantly, so this was not an edge case, it was every save.

follow_loop now stats the track's mtime alongside the path and re-parses on
either. Two extra stats per second; still no inotify, deliberately — a watch that
dies silently is the exact failure class this rig keeps producing.

One subtlety in the fix: touched-state is cleared on a track CHANGE (carrying it
over would claim you had already worked controls on a track you just opened) but
PRESERVED on an edit to the track already loaded. Otherwise a ctrl+S mid-set
wipes the one thing that display exists for.

== 2. HELPERS ARMED BY NAME: four live buttons painted as unmapped ==
PLN: "i expect filters and mutes on all and the ^41 as the mask control no?"

Every ParVagues orbit is written `dN $ gF2 $ gM3 $ ...`, and BootTidal defines
`gM3 = gMask . gMute3` — so ONE name arms TWO controls, and a "^NN" scan of the
.tidal sees neither. On 5 of the 13 OPAL tracks (do_it_right, vague_de_crime,
desire, the_revolution_will_be_sampled, electric_hammer) ^41 and all three mutes
sat DARK while live. Dark means "not mapped here"
(feedback_dark_means_unmapped_outranks_all), so the board was asserting that four
of the most-used buttons did nothing.

parse_track now resolves gMask / gMute1-3 / gM1-3 to their CCs. Role is the
neutral "fx", not the invoking orbit's role: the mutes are SHARED (bombe_dj
drives gMute3 from d4, d5 and d7), so an orbit-derived role would be whichever
orbit the parser happened to see last. A stable colour beats an arbitrary one;
refining button colour is #49/#51.

== THE NEAR-MISS WORTH RECORDING ==
I first "verified" this fix against bombe_dj and measured NO change — 28 bindings
before, 28 after — and was about to conclude the whole diagnosis was wrong.
bombe_dj is one of the 8 tracks where those CCs happen to appear literally
somewhere in the file, so it cannot show the bug at all. Running the comparison
across all 13 tracks instead of the one in front of me is what recovered it.
A single-file spot-check disproving a real bug is a worse outcome than no check.

Tests: 6 new cases in at/tests/test_lcxl_colour.py, one per SHAPE rather than per
file — gM3 lights both mask and mute, each gM variant selects only its own mute,
bare gMask/gMute names resolve, a COMMENTED helper lights nothing (same rule as a
commented ^NN — a disabled helper is not a binding), and a track arming no
mask/mute leaves those buttons dark. 42 pass in the colour suite, 165 in the
full tools suite.