Splitting a sped-up clip and deleting the middle leaves the deleted footage
in the export and drops a matching stretch from the end of the recording.
`ClipRegion.startMs` is a source position while the split position is a
timeline position, and the two only coincide at 1x. `handleClipSplit`
assigned the timeline position as the right half's source start, so at 2x
the right half re-read footage the left half already covered. Cutting the
10s-20s playback window out of a 2x clip removed source [100s,120s] instead
of [20s,40s]: nothing in the middle was cut and the last 20s of the
recording silently disappeared.
Anchoring the right half at the source time the split maps to fixes the
export, but it would also drag the clip across the timeline, since the clip
row draws items at `startMs`. So separate the two meanings: `sourceStartMs`
says where a clip reads from, `startMs` stays where it sits. It falls back
to `startMs` when absent, so stored projects behave exactly as before and
need no migration.
Left-edge drags in `handleClipSpanChange` were wrong in the same way and now
advance `sourceStartMs` by the source the trimmed edge covered; moves carry
their footage along unchanged.
The split itself moves into a pure `planClipSplit`, matching how
`planClipSpeedChange` is already factored, so it can be covered by tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ZyJLpqdwGjGvR4yy44xWU
webadderall