video-mode: a selector trim start never lands after a highlight (fixes main CI)

[mmkal]

Main CI has been red since #38 (a65cda0): reveals an expanding textarea one line at a time at its final geometry fails 2/2 there with frames 0-1 showing the filled text before the reveal — the render window starts after the fill. It never reproduces locally (3/3 green), which fits the cause:

#38 calibrates the render window from the calibration cover. On a slow runner the screencast trails the paints it maps by a few frames, and the cover-based offset inherits that lag — so a selector-driven trim start (trimStart: ["selector", ...]) can land past the first fill. The existing race guard only clamped a trim start back to a highlight when it landed within one frame after it; CI's lag is bigger.

Nothing acts on the app before it's ready, so any trim start after a recorded highlight is measurement error, and starting at the highlight is always harmless (the video opens on the action instead of a beat before it). The guard now clamps unconditionally:

// before: a start ≤ 1 frame after a highlight moved back to it; further = kept → opens post-action
// after:  a start after any highlight moves back to the earliest such highlight

No new spec: the failure is runner-timing-specific and this PR's CI run is the verification. Unrelated: uses a normal pointer tail after text cursor holds is a pre-existing local flake on main (1/3 fails with --repeat-each=3), untouched here.

Blocks #39's CI (inherited the same red).

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes render trim boundaries for all selector-driven starts when highlights precede the computed start; behavior is intentional but affects every video-mode render path that sets sourceRange.start.

Overview
Fixes rendered videos that could open after the first recorded action when trimStart uses a selector or cover-based calibration lags on slow CI runners.

During finalization, if sourceRange.start is set but sits past one or more highlight timestamps, the render window start is pulled back to the earliest such highlight. The previous guard only did this when the gap was within one frame; multi-frame calibration/screencast lag is now covered too.

Comments in video-mode.ts spell out the rationale: a trim start after a highlight is treated as timing error, and clamping to the highlight is safe because it keeps the opening frame on the action instead of post-fill footage.

^{Reviewed by Cursor Bugbot for commit c737189. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@40

commit: c737189