feat(cut-lens): v3 measures the crossfade as a span — and self-calibrates

v2 left a diagnosis, not a fix: every error was negative, and the accurate
boundaries were exactly the ones PLN called short. The lens finds where the
incoming track FIRST APPEARS; the ear marks where it TAKES OVER. Those differ
by the crossfade length, which is the varying quantity (2-41s on this set), so
a point estimator is the wrong shape of answer.

v3 reports a span. The part worth keeping is that the "fraction through the
fade" needs no tuning: evaluating the timbral series d(t) on the reference
windows themselves gives d(ref_prev) = -sep and d(ref_next) = +sep, so
u = (d + sep) / 2sep is calibrated by construction — u=0 is "identical to
before the switch", u=1 "identical to after", comparable across orbits and
boundaries. Every previous version thresholded a raw distance whose scale
differed per orbit, which is why no threshold ever meant the same thing twice.

The model behaves as predicted: u=0.15 sits 48s early (onset, confirming the
v2 diagnosis), and the error finally changes sign at u=0.7 (+1.3s mean, median
3.7s, vs v2's 16.6s and uniformly negative).

But it does NOT ship a number. Six of fourteen boundaries returned "no
separating orbit" — including #13 and #15, the two the run existed to answer —
leaving n=2 truth points against five candidate fractions. Coverage, not
accuracy, is now the bug: MIN_SEP gates on the distance between two 40s MEAN
profiles, and averaging that long over a livecoded track washes out precisely
the orbits that change. Next attempt gates on the reference windows' frame-level
distributions instead. Full result and reasoning in the module docstring.

Usable today as candidates only: #11 clusters inside 3.5s (short fade, nominal
~4s late), #12 spreads over 32s (long fade, nominal mid-span).