fix: smooth scrubber end seeking

[miguel-heygen]

Summary

Make end-of-timeline scrubbing settle cleanly instead of landing a few pixels short and visually jumping.

Root Cause

Near the right edge, the scrubber math could stop just short of the exact end of the seek bar. That left the thumb and time text to settle after the drag, which read as a jump.

Fix

• add an edge snap zone for scrubber seeking
• cover the behavior with focused tests
• keep the player seek path honoring the exact safe duration

Verification

• bun test packages/studio/src/player/components/PlayerControls.test.ts
• bun run --filter @hyperframes/studio typecheck
• bunx oxlint packages/core/src/runtime/player.test.ts packages/studio/src/player/components/PlayerControls.tsx packages/studio/src/player/components/PlayerControls.test.ts
• bunx oxfmt --check packages/core/src/runtime/player.test.ts packages/studio/src/player/components/PlayerControls.tsx packages/studio/src/player/components/PlayerControls.test.ts

Browser Proof

• verified near-end scrub behavior in Studio with agent-browser
• the thumb now settles at the exact end state instead of snapping after release

Stack

• depends on feat: add studio timeline editing #390

[miguel-heygen]

• fix: smooth scrubber end seeking #386 👈 (View in Graphite)
• feat: add studio timeline editing #390
• fix: stabilize studio preview and runtime sync #389
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[miguel-heygen]

Pushed 9025928a to address the remaining Fit scrubber-end jump.

What changed:

• Timeline no longer auto-scrolls to follow the playhead when zoom mode is fit
• the same guard also blocks playhead-drag edge auto-scroll in fit
• added a focused regression test for the fit/manual auto-scroll rule

Browser verification on #project/product-teaser-starter:

• scrubbed to the end state
• UI settled at 0:08/0:08
• timeline scrollLeft stayed 0 in Fit
• screenshot: /tmp/hf-scrubber-fit/fit-end-no-scroll.png

[miguel-heygen]

Pushed ff5671d3 to switch the timeline from px/s-based manual zoom to true percentage-based zoom.

What changed:

• manual timeline zoom is now stored as a percent relative to the current Fit width
• the toolbar shows true percentages instead of raw px/s
• Timeline derives effective px/s from fit width + manual percent, so zoom stays proportional across viewport/project changes

Sweep on #project/product-teaser-starter:

• initial: 100%
• after one -: 80%
• min clamp: 10%
• first + from min: 13%
• max clamp: 2000%
• back to Fit: 100%
• returning to Fit restored hidden horizontal overflow with scrollLeft = 0

Checks:

• bun test packages/studio/src/player/store/playerStore.test.ts packages/studio/src/player/components/timelineZoom.test.ts
• bun run --filter @hyperframes/studio typecheck
• bunx oxlint ...
• bunx oxfmt --check ...

[jrusso1020]

Focused fix, clean. Edge-snap math in resolveSeekPercent is well-bounded (Math.min(0.5, 8/width) prevents snap zones from overlapping on tiny bars) and the tests cover the cases that actually matter (invalid width, left-edge, right-edge, mid-range). Core player.test.ts pins the "seek to safe duration without snapping back a frame" behavior, which is the real root cause.

One non-blocking thing to eyeball in Studio if you haven't already: NLELayout.tsx flips the tracks container from overflow-y-auto to overflow-hidden. That's fine as long as vertical track scrolling happens at a different parent now (looks like it does, based on the new outer container), but worth a quick sanity check with many tracks.

Approved for alpha.

— Rames Jusso