PLN, after I misdiagnosed a decaying orbit as a sparse one: "do you lack tooling to
detect these over time? do you just listen to the loops once lol". Yes, and he was right.

THE MEASUREMENT BUG. probe-chain reported ONE peak/rms pair per orbit over the whole
capture window. That aggregate is mathematically incapable of showing a slope, and on
this rig the slope IS the diagnosis. d7 in vague_de_crime measured peak -22.5 / rms
-68.2 dBFS in a 14s window, and I read the 46 dB crest factor as "a sparse stab per
cycle, just buried in the mix". It was nothing of the kind: it was a pattern sounding
for ~3s and then dying, i.e. the `dN` = `xfade N` tail of the OUTGOING pattern while a
SILENT new one faded in. PLN heard it correctly from the first sentence — "I hear it on
ctrl+enter, then it fades in the back over 3s" — while my instrument said "quiet".

A sparse part and a dying part produce the SAME aggregate: low rms, one lone peak. That
ambiguity is not a judgement call to be made more carefully next time; it is missing
information, and the fix is to stop throwing the time axis away.

WHAT THIS ADDS. `probe-chain.py -t [BIN_S]` bins each capture (default 1s) into per-bin
rms and prints a sparkline plus a classification:

    DIED      loud at first, then silent for the tail -> xfade tail, the eval did NOT take
    DECAYING  >12 dB downward trend -> almost certainly an xfade tail, not a part
    RISING    fading in
    STEADY    a real, sustained part

Rendered as blocks with silence as a space, so a die-off reads as a visibly empty tail
instead of a number you have to interpret. It reuses the existing verified tap machinery,
so it inherits the contamination guard from 872676a2 — a row marked UNRELIABLE gets no
timeline, because a fabricated slope would be worse than a fabricated level.

VALIDATED TWICE. First against synthetic series, to prove the classifier can actually
separate the two cases that fooled me:
    xfade tail  [-12..-45,-inf x7]      |▇▆▆▅▄       |  -> DIED
    sparse part [-20,-55,-19,-58,...]   |▆▂▆▂▆▃▆▂▆▂▆▂|  -> (spiky, no dead tail)
    steady part [-18..-20 flat]         |▆▆▆▆▆▆▆▆▆▆▆▆|  -> STEADY
Then on the real rig, on the very orbit that caused this: d7 over 18s in 1.5s bins,
|▅▆▅▅▆▅▆▅▅▅▆▆|, STEADY -25.0 -> -23.4 dB. Flat. Confirmed by PLN's ears in the same
minute ("now its sticking i hear d7 stay").

ALSO HERE: check-mix.py no longer audits the wrong mixer. It hardcoded
"Tidal Multi/Tidal Multi.ardour" while the session in use is "Tidal Live" — so it
confidently reported five faders at -inf that were actually up, a stale file audited as
if it were live. It now resolves the session from the running Ardour process's own argv
(matching on cmdline, because the binary is ArdourGUI and `pgrep ardour` finds nothing —
a detail that already caused one wrong conclusion), falling back to Tidal Live by name.
A mixer auditor reading the wrong mixer is worse than no auditor.

Standing caveat unchanged and worth repeating: check-mix reads the session AS SAVED, so
unsaved fader moves are invisible to it. Same family as the trap found minutes later —
Pulsar evaluates the editor BUFFER, not the file on disk, so a grep of the file can
disagree with what is actually playing. Verify against the layer that is live.

Refs #26, #62, #65.