Clip id generator not seeded on open_project - edits after opening a saved project produce duplicate clip ids

[owenglenfehr]

Summary

After a project is opened from disk, the clip-id generator is not seeded
from the loaded timeline. The next edit that allocates a clip id reuses an
id that already exists, producing duplicate clip ids across the project.

Version / environment

v1.0.0-beta.5 (tag, merge 7349241), Linux x86_64, headless. The ten
opentake-* crates built with
cargo build --release --workspace --exclude opentake-tauri; MCP served via
opentake_agent::mcp::server::serve(). No Tauri shell. Edits issued through
MCP tools, so the path is agent dispatch -> opentake-ops.

Repro

1. New bundle with one video asset that has an audio stream.
2. add_clips at frame 0 for 300 frames. OpenTake creates a linked pair:
   video id-3, audio id-5.
3. Save, then reopen the project (in my case: restart the host process, which
   calls AppCore::new() then open_project).
4. ripple_delete_ranges ranges [[54,59]], trackIndex 0, units "frames".

Expected

The two new segments get fresh, unique ids.

Actual

track 0 (video)  id-3  start 0   dur 54    end 54
                 id-5  start 54  dur 241   end 295
track 1 (audio)  id-5  start 0   dur 54    end 54
                 id-4  start 54  dur 241   end 295

id-5 is now present on both tracks. Frame math is correct; the defect is
purely identity. Any later edit addressing id-5 is ambiguous.

Control

Without the reopen in step 3, the same sequence is correct — the new
segments get id-9 / id-10. The reopen is the trigger.

Impact

Opening a saved project and then editing is the normal desktop workflow, so
this is not MCP-specific. Duplicate ids compound: subsequent operations that
address a clip by id may hit the wrong one.

Possibly related, not isolated

In one longer session (add_clips, two failed tighten_silences calls, two
host restarts, then a ripple) the audio track ended up with duplicate ids
and wrong start frames -- first audio segment at 54 instead of 0, and two
clips overlapping by 49 frames. I could not reduce that to a minimal repro;
the id collision above is the part that reproduces reliably.