check-drift flagged 13 uncommitted .tidal files as "the stale-buffer signature"
and its remedy section led with `git checkout -- <file>`. I nearly relayed that.

All 13 were PLN's own work: the ^43/^44 -> ^41 gMask-retirement migration
(37857225 freed ^41 for d1's gate) plus real musical edits — new octersubbus and
squizbus lines, `slow 2 $ ply 2` reworks, gain 1.4->1.6, a sample change from
n "74" to n "25". `git checkout --` would have destroyed a set the night before
the gig, on the advice of a check that was confident and wrong.

The script's own design comment already had the right principle: "drift is not
control numbers changed, it is control numbers moved AWAY FROM THE GRID". Its
per-file test just cannot see direction — it counts CHANGED ^NN lines (>= 4) and
ANDs that with a global grid failure. Both were true here for innocent reasons:
the grid is unaligned because the migration is HALF-APPLIED, and those files are
the half that is done. Volume of change cannot separate a repair from a
regression. Only direction can, and migrate-columns --plan already knows it:
0 pending moves for a file means its edits ARE the alignment.

So: the DRIFT message now names both hypotheses with the one command that
distinguishes them, the grid failure reports migrate-columns' pending count
(20 here) and spells out that UNALIGNED is not REGRESSED, and the destructive
remedy is behind an explicit "look at the diff first" with this incident as the
reason. A gate that recommends data loss on ambiguous evidence is worse than no
gate.

Still exits non-zero, honestly: 9 knobs are genuinely out of column and 20 moves
are genuinely pending. That is a real finding about an incomplete migration, and
completing it is a decision about muscle memory that belongs to the person whose
hands are on the desk — not something to apply the night before a gig.