Adds a sub-bar "chops" mode alongside bar-aligned "loops": analyze_chops segments a
stem by onset (librosa.onset_detect + backtrack) and offers onset→onset / onset→skip-one
slices (0.05–2.0 s), scored on the seam/zc/level rules a short chop still must honour
(bars=0 marks a chop). find_takes(mode=) selects it; /api/loops takes mode; the GUI gains
a loops/chops dropdown per catch (header + waveform render chop durations). 9 finder tests.

HONEST measurement (not a recall win): chop-mode recall on the GT is 0.13 vs the
bar-loop 0.34 — WORSE. Two real reasons, both worth recording:
- PLN selects a few chops by TASTE from many onset candidates, so "did top-N contain his
  exact picks" is a harsh yardstick for a palette-browsing task; precision (0.15) confirms
  most onset slices aren't ones he'd keep. recall is arguably the wrong metric for chops.
- naive onset windows over-segment (clean seam on any short slice ≠ a musically useful
  chop). A better chop ranker would need transient saliency + pitch/word-boundary cues.
So LOOPS stays the default; CHOPS is an opt-in capability for when PLN is word-chopping a
vocal — it produces clean, auditioning-ready sub-bar slices (verified end to end in the
GUI: 0.06–0.51 s slices, waveforms, Forge), it just doesn't predict his selections. The
recall gap on chop-heavy sources is a genuine research problem, parked on #18 with this
finding rather than papered over. finder_eval_chops.json carries the numbers.