SuperDirt's boot runs MIDIIn.connectAll (start_and_midi.scd:19), so SC
subscribes to every hardware MIDI input it can see -- the LCXL included.
The surface then fed SC twice: once raw, once through Midi Through. And
MIDIFunc.cc takes `src` and never checks it (start_and_midi.scd:51), so
every CC fired the handler twice and every button noteOn double-fired
into ~lcxlChordCheck. A double noteOn on a toggle is a no-op: that is how
a mute button silently stops working.

lcxl3-driver's prune() handled this for the v3 board, but only while it
runs -- and it was stopped today (stale binding to an unplugged mk3,
Conflicts=-killing the mk1 painter). A hand-run `aconnect -d` fixed it
live and then SC restarted and re-armed it, which is the whole argument
for putting it in the reconcile loop that already owns the wiring.

Rule 3 matches the RAW board on type=kernel, never on name alone:
lcxl3-driver publishes a virtual port called 'ParVagues LCXL3' that
matches the same name candidates, and cutting the driver's translated
feed would kill the path we actually want. Only surface->SuperCollider
links are cut; -> Midi Through and the aseqdump taps that gig-log and the
Pulsar HUD read all survive, verified live.

Tested by arming the bug (aconnect 20:0 130:3, 20:1 130:4) and watching
the loop cut both and settle: lcxl-path.py went from "LCXL -> SC direct"
back to "LCXL -> Midi Through -> SC", logged once, no per-tick spam, and
gig-log kept counting touched controls.

Also logs PLN's ear-feedback on the classic-LCXL play-test (rose_rouge
works great; midiviz landed) to the archivist's notes.