fix(app): context-menu actions, clip clipboard, A/V drop, add-track, default tracks, undo divergence

- Right-clicking an unselected clip selects it first (C++ parity) —
  this is what made Cut/Delete appear to do nothing.
- Cut/Copy/Paste clipboard: clipboard_copy/cut/paste on the engine,
  clipboard clips keep footage/range/speed/track kind and stay linked
  in the pasted group; paste lands at the playhead as one undo entry.
- Dropping a video-with-audio footage places the video clip plus a
  linked audio clip at the same range in ONE 'Add Clip' undo entry.
- Add Video/Audio Track buttons in the timeline toolbar and the track
  header context menu; new sequences start with 2 video + 2 audio
  tracks (not an undoable edit).
- oaknode Graph::add_entry now reclaims the slot from the free list —
  before, a detached-then-reattached node left its slot in the free
  list, so node_count undercounted and the next add_node silently
  clobbered the restored node. This was the user's 'undo, redo, undo,
  redo and the result changed' bug; regression covered by cycle tests
  (move/trim/delete/split/add-track/linked-placement all converge).

crates/oaknode/src/graph.rs

@@ -111,7 +111,12 @@ impl Graph {
 	pub fn add_entry(&mut self, entry: NodeEntry, id: NodeId) -> NodeId {
 		let index = id.index();
 		if (index as usize) < self.entries.len() && self.entries[index as usize].vacant {
-			// Original slot free: reuse (index, generation) unchanged.
+			// Original slot free: reuse (index, generation) unchanged. The
+			// slot was pushed to the free list by `take_node` — reclaim it,
+			// or `node_count` keeps undercounting and, worse, the next
+			// `add_node` hands the same slot out again and silently
+			// clobbers the restored node (the undo/redo divergence).
+			self.free_list.retain(|&i| i != index);
 			let generation = entry.generation;
 			self.entries[index as usize] = entry;
 			return NodeId::new(index, generation);