fix: line-wrap-split typing masquerades as an extra prompt submission

[htlin222]

The bug

A real record-session --robust demo (3 turns: a short Q&A, then a long
27-word/3-line prompt, then /theme) produced a badly desynced final video:
turn 1's (the long-prompt turn's) hard segment came out only 6.16s long — too
short to even contain its own scripted typing duration (6.74s), let alone the
real ~8.1s of Claude thinking+response that followed. Downstream, the frozen
freeze-frame chosen for the next turn's "pre" segment sourced from mid
sentence, so a half-typed prompt sat frozen on screen for ~23s while
unrelated narration ("turn 1 done" / "now watch /theme") played over it.

Root cause (confirmed against the real capture's pixels, not guessed)

detect_anchors.signals() auto-locates the "input band" it tracks as a
FIXED, ~5-row-tall window near the bottom of the frame — deliberately tight so
response content doesn't leak in. That's fine for a short, single-line
prompt. But when a prompt is long enough to wrap onto a new line, the
input box grows a row: the just-typed line's content shifts out of that fixed
band and the freshly wrapped (still-blank) line takes its place. That's a
sharp brightness drop followed by a climb as the new line fills in —
pixel-for-pixel the same "type-then-Enter-clears" shape detect_turns uses
to mean a real submission, even though the user never stopped typing.

Measured on the real repro: one continuous typing burst produced two
"submits" 1.52s apart (raw frames 386 and 424 @ 12.5fps), with peaks at 100%
and 93% of the frame's global max brightness — i.e. genuinely strong, not
the weaker spinner/response leakage the existing "keep the N strongest peaks"
disambiguation already knew to filter out. With 4 raw groups detected for 3
scripted turns, that logic kept both wrap pieces and discarded the turn
that actually owned the 4th (weaker, correctly-detected) group — corrupting
that turn's own submit and starving the preceding turn's done search
window (which is bounded by the next detected group's start).

Confirmed via frame-by-frame extraction (ffmpeg -ss ... -frames:v 1): at
the exact raw timestamps the old code treated as "Enter pressed" for the long
prompt, the terminal screenshot still shows the sentence being actively
typed, with a live cursor — no Enter has happened yet.

The fix

In detect_anchors.detect_turns(), fuse adjacent detected groups into one
before any n-vs-count reasoning, when all three hold:

1. short gap (≤2s — generous vs. the ~1.5s dip measured; a real turn
   boundary always has a multi-second settle/think/PAD gap; back-to-back
   instant turns are handled by the separate, existing
   _recover_merged_instant_groups path and never show a partial dip like
   this);
2. both flanking peaks genuinely near-max (real typed text, not moderate
   spinner leakage);
3. the gap is RISING, not idle — a real Enter leaves the input band idle
   at its post-clear floor for the whole gap; a wrap dip instead climbs
   almost immediately because the same typing burst is still going. This
   is what actually distinguishes a wrap dip from two short-but-genuinely-
   distinct back-to-back turns (which can also have a short gap with
   near-max peaks either side) — gap-length or peak-strength alone aren't
   enough on their own.

Fixing this correctly re-surfaced a second, separate, pre-existing edge case
in this same demo: the final turn (/theme, a native menu) never shows a
real Enter-clear at all before the raw capture ends (the recording stops
while the menu is still open), so its detected group runs to the raw video's
very last analyzed frame. submit in that case just means "recording
ended here" — the existing +0.3s floor on done was pushing the segment
past the video's own reported length, which broke the freeze-frame splice
downstream (no frame exists past the file's own duration). Added a matching
clamp (with one frame of slack, mirroring BootStrategy's existing "at end"
convention in strategies.py) so done for the last turn never exceeds the
raw capture's own length.

Testing

Per CONTRIBUTING.md's testing ethos, the exact failure mode is reproduced
as synthetic pixel-array unit tests (using the real measured peak
values/gap/timings) in tests/test_detect_anchors.py, verified to fail
before the fix and pass after:

• test_merge_same_burst_groups_fuses_wrap_split_typing
• test_merge_same_burst_groups_leaves_distinct_turns_alone
• test_merge_same_burst_groups_leaves_weak_spinner_leak_alone
• test_detect_turns_wrap_split_no_longer_starves_neighbouring_turns
• test_detect_turns_last_turn_done_never_exceeds_raw_video_length

134 pre-existing tests still pass unmodified; 139 total, all green.

I additionally used a real --robust capture exhibiting this exact bug (not
committed — see below) to diagnose the root cause via direct pixel/frame
inspection, and to verify end-to-end: re-running detect_anchors + author.py

• splice.py against it now produces a properly-sized hard segment for the
  long-prompt turn (18.44s vs. the previous 6.16s, correctly containing the real
  submit and enough room for the actual response) and the full splice pipeline,
  which previously crashed on the newly-surfaced /theme edge case, now
  completes successfully.

On the real repro fixture

I did not commit the real capture used to diagnose this (terminal_raw.mp4 +
its capture/script/ledger/timeline siblings). The repo's .gitignore
excludes *.mp4 repo-wide save one existing hero asset, and
CONTRIBUTING.md states the unit test suite intentionally needs no external
tools (ffmpeg/vhs/tmux) to run. The synthetic tests above already
reproduce the precise pixel shape (constructed from the real measured
peak/gap/climb values), so I judged a large committed binary fixture wasn't
worth the added repo weight/precedent. Happy to reconsider if maintainers
would rather have it as a -f-added fixture.

Scope note: is this robust/tmux-specific?

Inconclusive either way from what I could test in the time available — I
did not get to build a comparable standard (non---robust, non-tmux)
capture with a similarly long, wrapping second-turn prompt to compare
against. The mechanism itself (a fixed-row input-band tracker losing a line
to box growth on wrap) is a property of signals()'s pixel-band tracking,
not of --robust/tmux capture specifically, so I'd expect it to reproduce
under standard VHS capture too given a long enough wrapping prompt — but
that's inference, not something I verified against a second real capture.
Worth confirming with a standard-mode repro if it matters for prioritization.

Issue-filing for this bug is left to the orchestrator/maintainer if still
wanted — no existing issue number is referenced here.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com