feat(studio): show both sides of the cut while trimming

[miguel-heygen]

Stacked on #3341 (the trim tools). Review that one first; this branch is
only the last commit. Before merging the stack, retarget this PR to main
and rebase — deleting #3341's branch on merge would auto-close this one.

What

The FCP-style precision view from #3285: while a trim tool is active, a two-up
panel above the timeline holds the frame on each side of the edit point, live,
as you drag it.

Left pane is the outgoing frame, right is the incoming one, with the running
trim amount between them. A finished trim leaves its cut on screen rather than
snapping back — it is the frame you just made.

Why

The trim tools move an edit point, but the preview only ever shows one frame,
so the frame you are cutting away and the frame you are cutting to were
never on screen at the same time. That is exactly what the issue asked for, and
it is the part of a trim you cannot judge from the timeline bars.

How

• Each pane is its own preview iframe of the current composition, seeked to its
  own time — the same live-preview-in-an-iframe pattern the composition cards
  already use, so no new rendering machinery. Seeks are imperative: re-rendering
  the iframe per pointer move would reload the composition every frame.
• The gesture and the panel meet through one small store slice: the trim
  publishes the pair of composition times it is editing, the panel reads them.
  The gesture lives deep in the timeline's drag hook and the panel renders above
  the timeline, so props would have meant threading state through five
  components.
• Slip has no edit point, so it shows the clip's own first and last frame —
  what its drag actually changes — labelled "Clip in" / "Clip out".
• Panes are letterboxed to the composition's authored size, so a 1920×1080 comp
  shows the whole frame rather than the top-left corner of it.
• Idle (tool armed, nothing dragging) the panes straddle the playhead, which
  also keeps them warm: a composition takes a moment to load and a pane that
  arrives after the gesture is over is worth nothing.

On the cost. Two extra composition renders is real, so the panel exists only
while a trim tool is active, and a toolbar toggle (persisted in the studio UI
preferences, default on) turns it off. Switching it off tears the iframes down
rather than hiding them — verified below.

Test plan

• Unit tests added/updated — 3 new tests covering which edit point each mode
  frames (out-point ripple follows the drag, head ripple pins the start,
  roll and slide follow their moving boundary), slip framing the clip's own
  in/out, and the clamp that stops a negative preview time.

• Manual testing performed — drove a real Chrome against Studio and read the
  panel's own labels back out of the DOM:

  Step	Observed
  Select tool	panel hidden
  Roll tool	panel shown, 3 preview iframes alive (main + 2 panes)
  Toggle off	panel gone, back to 1 preview iframe
  Toggle on	panel shown again
  Roll the A|B cut +2s	Outgoing · 9.97s │ ROLL +2.00s │ Incoming · 10.00s
  Release	the trimmed cut stays on screen

  Frames verified by eye, not just by label — the panel after that roll:

  

• Full packages/studio suite green (4311 tests), typecheck, oxlint, oxfmt.

Not covered

• Dragging the cut inside the panel itself. FCP lets you trim from the
  precision editor; here it is a readout and the timeline stays the input
  surface. Worth adding if the view earns its keep.
• Filmstrips of the surrounding source either side of the cut. Two frames,
  not two strips.
• The panel is a fixed 132px band above the timeline; it is not resizable.

[miguel-heygen]

Closing for now. The two panes are iframes of the unedited composition seeked to a time, which cannot render a clip outside its current window, so half the gestures show the wrong clip in one pane:

Gesture	Outgoing pane	Incoming pane
Ripple A's out point left	clip-a (correct)	clip-a (should be clip-b)
Roll A|B right	clip-b (should be clip-a)	clip-b (correct)
Roll A|B left	clip-a (correct)	clip-b (correct)
Slide B right	clip-b (should be clip-a)	clip-b (correct)

Measured by reading which clip each pane's own document actually renders, mid-drag. The delta readout and the outgoing side of a shortening trim are the only parts that hold.

Fixing it means the panes have to render the projected edit rather than seeking the unedited composition, which is a redesign rather than a formula change. #3347 has been retargeted onto #3341 so the trim tools and the fade handles can go in without it.