The compaction renames a `dN` declaration; it deliberately does not touch that
orbit's knobs and buttons. So the moment 150 orbits moved, their controls were
sitting on the column of an orbit that no longer existed there — d6 answering
to column 7 in 84 files. The two tools are one job in two passes and only the
second pass closes it.

Found by accident, which is the part worth recording: ete_a_mauerpark reported
"0 move" right after the compaction, then reported 4 the moment something else
made me re-plan it. A conformance check run once, before the step that breaks
conformance, proves nothing.

202 moves, 84 files, 0 clashes. Re-plan now reports 0 across all 703. Button
conformance 93.3%, no CC gained inside the Ardour-learned or gF ranges, and the
third full silent-eval sweep diffed per-file against the baseline: zero verdict
changes. The seventeen-track set re-validated on its own afterwards — all 17 OK,
pvlint 0 errors.

Also in here, from reading ete_a_mauerpark's d9 to answer PLN's "[confirm d9
effects]" note: its attack was riding `^16`, which is A4 — d12's LEVEL knob,
MIDI-learned to an Ardour track gain. One knob moved an Ardour fader AND d9's
attack, the CC77-goes-to-silence class the driver header warns about. Moved to
`^20`, idle in this track. Its `mask` on `^58` is d6's own gate and d6 IS
declared here, so one button drives two orbits — left alone on purpose: d9 has
no button slot in the grid at all, so that is gSel work, not a rename.