fix: keep zoom selection on the new segment after a split

[JebKJ21]

What

Splitting a zoom segment and then editing the newly created piece could silently edit the pre-split segment instead: splitZoomSegment re-sorted the segments array but left editorState.timeline.selection pointing at the old index — which after the sort can belong to the other half. The user then adjusts "the new zoom" while the changes land on the old one, and playback keeps zooming into the old area (#2230).

Fix

• splitZoomSegment now keeps the selection on the new (right) piece after the split + re-sort.
• The split geometry moved into a pure helper, zoom-segments.ts (splitZoomSegmentAt), which computes the new piece's post-sort index where the mutation happens and can be unit-tested without Solid stores.
• The clip split already resets selection after re-ordering (the didSplit branch); zoom splits now follow the same principle instead of leaving a stale index.

Testing

• New unit tests (zoom-segments.test.ts, 5 cases): split geometry, property preservation on both halves, post-sort selection index, <1s rejection, out-of-bounds no-op.
• vitest run in apps/desktop: 32 files / 270 tests pass.
• biome check clean on touched files; tsc --noEmit clean.

Fixes #2230

If the team prefers to route this through Algora as a funded bounty, happy to submit it there — otherwise glad to have it reviewed as a regular contribution.

Confidence Score: 4/5

The PR should not merge until the helper preserves the new right piece's identity across sorting, because reordered inputs can still select the wrong segment.

Findings

1.  Sorting loses segment identity ▶

Prompt To Fix All With AI

### Issue 1
apps/desktop/src/routes/editor/zoom-segments.ts:34-36
`sortTrackSegments` sorts the array in place before `segments[index + 1]` is evaluated. If sorting moves the newly created right piece, this lookup instead finds whichever segment now occupies that position. For example, splitting index 1 in `[0–10, 30–40, 20–25]` returns the left piece's index, so the editor selects the wrong segment and the selection bug remains.

```suggestion
	const newSegment = segments[index + 1];
	const newSegmentIndex = sortTrackSegments(segments).indexOf(newSegment);
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

• Preserves zoom properties and enforces the existing one-second minimum.
• Adds unit coverage for geometry, property preservation, boundaries, and a normal sorted-array case.
• The new-piece index calculation still loses the inserted object's identity when sorting changes its position, so the intended selection fix is incomplete.

[greptile-apps]

Sorting loses segment identity

sortTrackSegments sorts the array in place before segments[index + 1] is evaluated. If sorting moves the newly created right piece, this lookup instead finds whichever segment now occupies that position. For example, splitting index 1 in [0–10, 30–40, 20–25] returns the left piece's index, so the editor selects the wrong segment and the selection bug remains.

Suggested change

	const newSegmentIndex = sortTrackSegments(segments).indexOf(
	segments[index + 1],
	);
	const newSegment = segments[index + 1];
	const newSegmentIndex = sortTrackSegments(segments).indexOf(newSegment);

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/desktop/src/routes/editor/zoom-segments.ts
Line: 34-36

Comment:
**Sorting loses segment identity**

`sortTrackSegments` sorts the array in place before `segments[index + 1]` is evaluated. If sorting moves the newly created right piece, this lookup instead finds whichever segment now occupies that position. For example, splitting index 1 in `[0–10, 30–40, 20–25]` returns the left piece's index, so the editor selects the wrong segment and the selection bug remains.

```suggestion
	const newSegment = segments[index + 1];
	const newSegmentIndex = sortTrackSegments(segments).indexOf(newSegment);
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[JebKJ21]

Good catch — fixed in 42d704c. The inserted piece is now captured by reference before sortTrackSegments runs, and splitZoomSegmentAt returns null if the identity lookup ever fails, so the selection can't drift onto the other half. Added a regression test where the sort moves the new piece past a later segment.