feat(tools): take-lens — read a recorded take through the gig log, and find the trims

PLN asked for "a master split per track loaded time, cleanup parts obviously
'practice or plugging in' that are scarce VS intro/outro (can we detect this? did we
record play metadata as the ardour records?)".

Three datasets existed and had never been joined:
  - Ardour names sources `Take<N>_Tidal <orbit>-<seq>%<L|R>.wav`, so the take number
    plus the frame count plus the mtime give an exact wall-clock window with no
    session-XML parsing at all.
  - gig-log has coalesced MIDI CC at 1 Hz: 29862 events over this take, on 46
    distinct controllers. Hands-idle is the clearest signature of "plugging in".
  - per-orbit RMS/peak says what the SOUND did.

The third one is not optional, and that is the design insight. Idle hands ALONE is
ambiguous: you can play a part for three minutes without touching a knob. So a
candidate is classified by what the audio was doing underneath it — `dead` (nothing
above -60 dBFS: safe to cut), `loop` (a couple of orbits droning, hands off:
probably plugging in), `playing` (most orbits going: a real part, KEEP). On take 94
that distinction earned its keep immediately: of three hands-idle runs, two were
real parts at 8 and 4 orbits average, and only the 75s tail was actually dead.

FINDINGS ON TAKE 94 (21.1 min, 20:08:33 -> 20:29:41, 12 orbits)
  - 8 of 12 orbits peak OVER 0 dBFS, worst d4 at +9.63 dB. The files are 32-bit
    FLOAT, so this is headroom and not damage — a gain cut recovers it exactly, and
    it only becomes real clipping on integer export or at the master bus. Labelling
    it "CLIPPING" would have been a false alarm sending him to re-record material
    that is completely intact, so the tool now reads the subtype and says which it
    is. A uniform -16 dB on the record bus lands the hottest orbit on the -6 dBFS
    source target.
  - d12 silent for the whole take (-78 dBFS).
  - no track timeline: nothing published the loaded track while it recorded. The
    tool says so plainly instead of guessing, because a confident wrong boundary is
    worse than none — the existing Bandcamp splits carry crossfade bleed for exactly
    that reason. Takes from d5baca32 onward split exactly.

A MEASUREMENT TRAP, RECORDED IN THE CODE
The first pass estimated duration as size/(sr*3), assuming 24-bit. These files are
32-bit float. That put take 94 at 28.2 min starting 20:01:30 instead of 21.1 min
starting 20:08:33 — and manufactured a "6m15s dead intro" that never existed, purely
from a 7-minute window shift. The fallback now assumes 4 bytes and, more
importantly, exact lengths come from the frame count and estimated ones are labelled
"do not cut from it".

Also: logs_covering() checks EVERY log's [first,last] range rather than assuming the
newest one holds the window, because a take can straddle a recorder restart — which
is exactly what happened today.

It proposes, it does not cut: output is a report plus an EDL JSON for
armada/tide-table/edl_render.py. Trims are a taste call and the ear is the gate.