The timing gate and a migration command

[LeadcodeDev]

Part of #326. Batch 4 — depends on every other workstream.

#336 changes how a scenario's total duration is computed, which is a real behaviour break: a file with five transitions gets 1.5 s longer. That change sits behind "timing": "v2" so nothing breaks unasked, and the gate is only honest if there is a way across it.

Owned files

• crates/rustmotion/src/cli/commands/migrate.rs (new)
• crates/rustmotion/src/cli/commands/validate.rs, validation.rs

Do NOT write: any schema file, anything under engine/.

Deliverables

1. rustmotion migrate -f x.json converts a scenario to timing: v2, compensating each scene's duration by its own transition length so the output is frame-identical to the pre-migration render. It refuses a templated file, or one using include, for-each or use, for the same reason --fix already does.

2. Validation ordering. Geometry runs after static folding, so a computed position is checked as the value it resolves to rather than as an expression string.

3. The new checks wired into validate. expression_error and reference_cross_scene from Let scenario values be arithmetic expressions #327 and Let a node read another node's geometry and a text's measurements #328, unresolved_beat_unit and off_grid_cut from Place scenes on an absolute timeline with a beat grid #336, with --lenient downgrading them consistently with the existing ones.

Acceptance

• rustmotion migrate on the six-scene reel produces a file rendering the same 13.5 s it rendered before, frame for frame
• A migrated file then opting into snap: "beat" renders 15.0 s with cuts on the grid
• rustmotion validate --report carries every new violation kind

[LeadcodeDev]

Delivered on main at 187cf7c (squash of #340). Verified present on main, not taken on the PR's word.