feat(studio): audio gain on G, speed in clip names, additive selection and partner clamp (8/8)

[vanceingalls]

Summary

The Premiere polish pass:

• clip names show speed as [150%] / [ramp]
• one fx badge per clip
• an Audio Gain dialog on G
• Link for any unlinked video + audio pair
• Shift/Cmd-click additive selection
• audio kept inside its partner video while dragging and trimming
• Look previews on hover
• Unlink leaves nothing selected

Changes

• studio:
  • [NN%] / [ramp] clip names, and a single fx badge in place of the per-tool and link badges.
  • AudioGainDialog on G (one undo step). Shortcuts are kept out of the modal, and it refuses while recording.
  • Link for exactly one unlinked video + one unlinked audio (same source → sync origin).
  • Shift/Cmd-click add to the selection.
  • An audio clip with a partner video (linked or same sync origin) can't move or trim outside the video span, and the drag actor holds at the clamp.
  • Look ▸ previews on hover and commits on click.
  • Unlink (menu, ⌘L, Alt-edit) clears the timeline selection.

Testing

Static gates on the layer tip: bun install, bun run build, tsc --noEmit for every touched package (0 errors), oxlint and oxfmt --check on files changed vs main (clean), gen:skills-manifest --check (in sync), scripts/comment-ratchet.mjs (ok).

• Scoped vitest: sdk 574, studio 6434. All pass. This tip's tree equals the full feature branch.
• Mutation check: removing the unlink clearSelection fails the new "unlink leaves nothing selected" test.

Notes

• Root cause of "after unlinking, trimming the audio still moves the video": setResizingClip seeds the trim gesture from the whole selection. After Unlink both clips stayed selected, so upstream's multi-select group resize trimmed both. Unlink now clears the selection. Trimming with both clips deliberately selected still trims both, by design (upstream's restored multi-select group resize).
• Studio's Shift-click time-range popover is replaced by Shift/Cmd additive selection (Premiere convention). Flagged for a product decision.
• Part of the audio-on-video stack. See the bottom PR for the overview.

🤖 Generated with Claude Code

[jerrai-bot-heygen]

Reviewed the #4821 delta at exact 49a5b9b0e2341e69d63d83eed3e65552b43aef23 against stacked #4820 ca563f775fcd9f0adba2c468f538f1dca6d6d037. Two inline holds: SDK linked-duration edits can push an offset audio partner past the video endpoint; and Studio's detached-audio containment runs before collision placement (and only for the grabbed element), so the final moved audio can escape the video. Current-head Comments is also red on five raised-comment-share files. #4820 and earlier stack layers remain held; this review is of this incremental delta only. No local browser, tests, merge, or release action. — Jerrai

[jerrai-bot-heygen]

When linked clips share an end but have different starts, copying the grabbed clip's duration moves the partner's end. Example: video [2,8] (duration 6) and audio [3,8] (duration 5), both linked. session.setTiming(video, {duration:4}) applies video [2,6] and then this sets audio duration 4 → [3,7], so the audio extends one second past its video even though this delta promises it stays inside. The new session test checks linked start movement; the duration test uses equal starts, which cannot catch the offset. Preserve the common end (derive partner duration from its own start and the new end) and add an unequal-start test.

[jerrai-bot-heygen]

The detached-audio/video bound is applied to previewStart, but resolveDropPlacement can move it outside that bound to avoid another clip, and line 200 returns placement.start without reclamping or rejecting it. Concrete same-lane case: video [10,30], its audio [12,20] (duration 8), obstacle [20,30]; dragging audio toward 22 clamps to 22 (the last bounded start), but nearest-free placement prefers 30 over 12, and timelineClipDragCommit.ts:240–244 persists audio [30,38]. Also, the bound is computed only for drag.element, not audio carried as a passenger of a multi-selection; dragging selected text and audio moves the audio via resolveMultiSelection without its own bounds. Please constrain final placement and each held audio mover, and test collision and non-audio-grabbed multi-select cases.

[github-actions]

Edit accuracy: 530 passing here, 530 on the base branch

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

[jerrai-bot-heygen]

Re-reviewed #4821 at exact a64a9ad1a50bb07930492362c083ba1a9d77f3f4 against current #4820. The unequal-start/shared-end duration repair and the Studio collision/passenger clamp address the previous examples; Comments and SDK/Studio checks are green. One boundary in the duration repair still breaks the linked containment promise (inline): a valid short video-duration edit can end before the audio starts, the computed partner duration becomes nonpositive and is silently skipped, leaving the old audio span beyond the video. Please define and test the crossing behavior. Current-head Studio/player captures and file-size checks also fail; no live UI or audio validation was performed. Other stack layers remain separately held. No merge or release action. — Jerrai

[jerrai-bot-heygen]

This repairs unequal-start durations only while the new shared endpoint remains after the partner's start. With linked video [2,8] and audio [3,8], setTiming(video,{duration:0.5}) makes the video [2,2.5], computes partner duration -0.5, and silently returns undefined; applySetTiming commits the video but leaves the audio [3,8] outside it. No SDK rejection runs before the first mutation. Please reject this edit atomically, remove/retime the partner under an explicit policy, or otherwise preserve the linked/containment invariant, with a regression at this crossing boundary.