[Feature] Add multi-level undo/redo to the editable Replay timeline

[chdenat]

Context

The editable Replay timeline will allow users to move and resize clips, add or remove clips, edit clip parameters, and reorder widget tracks.

Users need to safely experiment with these changes and return to previous timeline states without affecting Replay playback state or the rest of the application.

Requested behavior

Add a multi-level undo/redo history to the editable Replay timeline.

The history must apply only to timeline authoring operations, including:

• moving a clip;
• resizing a clip;
• adding or removing a clip;
• editing clip parameters;
• reordering widget tracks.

Playback, pause, replay, scrubbing, and the current playhead position must not create history entries.

The initial implementation should keep a bounded in-memory history for the current editing session. Persisting the undo/redo history in the database is out of scope.

Acceptance criteria

• Users can undo several consecutive timeline edits.
• Users can redo edits that were undone.
• A new edit after an undo clears the redo branch.
• Continuous pointer gestures create one logical history entry rather than one entry per pointer event.
• Timeline playback and scrubbing do not modify the undo/redo history.
• The mandatory replay track and its structural constraints remain valid after undo and redo.
• Undo and redo restore the normalized timeline model and refresh the timeline projection.
• Replay preview, Draft recording, and HQ export consume the restored timeline consistently.
• Undo and redo are unavailable when their corresponding history stack is empty.
• The history is bounded to a documented maximum number of entries.
• Automated tests cover stack navigation, redo invalidation, grouped gestures, scrubbing exclusion, and timeline constraint preservation.

Notes or questions

The initial history should be session-only and scoped to the editable timeline.

The read-only timeline preparation preview is not included in this issue.

Technical notes

• The history should operate on the normalized editable timeline model, not on the visual timeline package state.
• Store immutable timeline snapshots or an equivalent reversible representation.
• Keep the Replay store, canonical frame clock, and scrubbing scheduler outside the history model.
• Timeline restoration must preserve the existing separation between authoring state, runtime Replay state, and derived projection state.
• The implementation should integrate with the existing Replay timeline model and migration strategy.