fix: detect_anchors recovers consecutive instant-turn submissions via scripted timing

[htlin222]

Closes #18.

The bug

Two client-side-only turns back-to-back (e.g. /context then /fast on,
with no real model-invoking turn between them) have no "thinking gap" for
detect_anchors.py's pixel-based turn detector to split on. The merged
input-band signal reads as ONE continuous group instead of two, so the
detector undercounts prompt submissions and author.py fails with:

detected 3 prompt submissions, expected 4. Tune the input band / thresholds, or the recording differs.

The fix

detect_turns() already receives each turn's instant flag (written by
gen_capture_tape.py's render() into capture.json's per-turn plan, per
PR #16 / #19) via the existing turns parameter — no call-site signature
change was needed.

When len(groups) < n, a new recovery path checks whether the shortfall is
exactly explained by one or more maximal runs of consecutive instant
turns collapsing into a single detected group. If so, it splits the merged
group back apart using the known scripted timing — each instant turn's
settle Sleep + pre_enter + the next turn's type_dur — instead of trying
to re-detect the split points from pixels (there's no pixel signal left to
re-detect from). If the shortfall isn't fully explained this way, it still
raises: this is a targeted recovery for a known deterministic failure mode,
not a blanket excuse to swallow a genuine detection miss. The existing
len(groups) > n "strongest peaks" fallback is untouched.

While rebasing onto main I picked up the just-merged #17/#19 fix (native
CLI menu turns, e.g. /theme), which gives those turns the same
instant flag/shape but can use a longer settle (NATIVE_MENU_SETTLE
under --tmux) than the no-menu INSTANT_SETTLE. My recovery originally
assumed a single hardcoded settle constant, which would have silently
mis-timed (not raised, just produced wrong offsets for) a merged run
containing a native-menu turn. Fixed by having gen_capture_tape.py record
the settle it actually used per-turn (turn_plan["settle"]) and having the
recovery read that value (falling back to INSTANT_SETTLE for older
capture.json plans that predate the field).

Tests

• tests/test_detect_anchors.py::test_detect_turns_recovers_merged_consecutive_instant_group
  — reproduces the exact 3-vs-4 mismatch from the issue with a synthetic
  merged input-band signal; confirmed it fails with the original SystemExit
  before the fix.
• tests/test_detect_anchors.py::test_detect_turns_recovers_merged_group_using_per_turn_settle
  — proves the recovery uses each turn's own settle value, not a hardcoded
  constant (regression test for the native-menu interaction above).
• tests/test_detect_anchors.py::test_detect_turns_raises_when_instant_shortfall_not_fully_explained
  — confirms a shortfall NOT fully explained by instant merges still raises.
• All pre-existing tests (including the len(groups) > n guided-selection
  path and the plain under-detection raise) still pass unmodified.

Local suite: 131 passed, 0 failed (.venv/bin/python -m pytest tests/ -q).

Not done

Did not run a real end-to-end record-session (capture → author → splice →
overlay → panel → lint) against a live claude session — that needs several
minutes plus real API usage. vhs/tmux/ffmpeg/edge-tts/claude are
all present in this environment, so it's possible to run later if desired,
but per the task's own guidance the unit tests (with a faithful synthetic
repro of the exact reported mismatch) are the primary bar here.

🤖 Generated with Claude Code