captions that follow the cut

[OrellBuehler]

The problem

captions_from_transcript wrote the transcript's source timestamps straight
into TextOverlay.start/end, which are timeline seconds. Its own doc comment
conceded the limit:

The segments keep the transcript's own timestamps, so they line up when the
asset sits at the start of the timeline at normal speed.

That is not a cut. The moment anything is trimmed, reordered, retimed or
silence-removed, source time and timeline time diverge and every caption is on
the wrong word. remove_silence — the op this app leads with — desynced every
caption it had just written, so the two headline social-video features could not
be used together.

Second problem: a whisper segment is a whole sentence. One sentence at size: 0.05 does not fit a 9:16 frame.

What this does

Timeline::captions (pure, unit-tested) projects each transcript segment
through the clips that actually show its footage — Clip::source_span_to_timeline,
honoring trim, speed and reverse. Captions land on the words that survived the
cut; words that were cut out get none. A sentence cut in half captions only the
half still in the cut, because chunking happens over the segment's whole
projected span and each line is then clipped to the clip.

It reads through for_render, so a muted track is as uncaptioned as it is
unheard.

Chunking comes with it: 4 words / 28 chars by default, timed by character
share — the honest approximation, since neither speech backend reports word
timings (TranscriptSegment has only a start and an end). Lines too short to
read merge back into a neighbour instead of flashing for two frames.

TextOverlay.generated marks what the generator wrote, so re-running after a
trim replaces its own set instead of stacking a second one — and leaves the title
the editor typed alone. clear_captions takes only the generated ones.

The bug the harness found

Captions are one lane of text at one screen position, so two at once is two
unreadable ones. The sample cut carries the same asset twice at different trims,
and both clips captioned the same words — two different lines drawn on top of
each other. Not exotic: a callback shot, or a full source parked under the edit.
First line in wins the slot, the next starts where it ends, and one with nothing
readable left is dropped.

Surfaces

• generate_captions / clear_captions — Tauri commands and MCP tools,
  replacing captions_from_transcript. The asset-scoped call had nothing left to
  offer: its one correct case is what the timeline-scoped one does anyway.
• The MCP instructions now say to caption last and re-run after further
  edits. An agent has no way to infer that from a tool list.
• Inspector's Text overlays section captions the whole cut and relabels to
  Recaption once it has, with Clear beside it.
• A Caption the cut agent-queue chip: analyzes whatever is in the cut but not
  yet transcribed, then captions.
• src/lib/captions.ts — bun-tested mirror, same arrangement as platforms.ts
  and smart-crop.ts. Unlike those it is faithful rather than approximate,
  because captioning is arithmetic all the way down — which is how the harness
  caught the collision above.

Verification

• 261 Rust tests (9 new), 52 bun tests (10 new), clippy and rustfmt clean.
• Driven end-to-end through the Playwright browser harness: captions on the cut
  as-is, then a 3s head trim → recaption moves every line with it; regenerate
  replaces without touching a typed title; clear leaves only the title; the
  agent chip reports Captioned the cut — 8 lines.