feat(info): report what a scenario's media assets actually are

[LeadcodeDev]

Closes the "media metadata readable from the scenario" gap (High/M). The second gap in this batch — secondary artefacts during render — is deliberately not delivered; reasoning below and in the issue filed alongside.

What was missing

Nothing answered "how long is this audio track" or "what size is this image". An author timing a scene against a track had to measure it somewhere else, by hand.

$ rustmotion info -f scenario.json
...
Media assets:
  audio track 1: audio "voice.wav" → 3.00s, 44100Hz stereo
  view 1 / scene 1 / layer 1: image "logo.png" → 200×150
  view 1 / scene 1 / layer 2: video "clip.mp4" → 3.00s, 1080×1920 @ 30.00fps

Why info and not a probe subcommand

info had just gained two sections (Springs, Text sizes) with the same walk-scenario-then-print-if-non-empty shape. A third follows it without duplicating the loading, the view/scene traversal or the container recursion — and keeps "everything knowable about this scenario" in one command instead of two to remember.

Assumed trade-off: info is no longer instant once a scenario references media. That is the same category of cost the previous sections already introduced (Skia text measurement), not a new one, and it stays bounded because no remote asset is ever fetched.

Each probe reuses what existed

• Audio goes through decode_audio_file — the same decoder every render uses, never a second path. The cost is a full decode, stated rather than hidden: this repository has no header-only audio path.
• Images use image's into_dimensions, a header-only read the crate already offered and nothing used. Every existing decode goes through Image::from_encoded, which rasterises in full to answer a question about dimensions.
• Video shells a single ffprobe -show_streams -show_format, mirroring the existing ffmpeg_available() guard, and never decodes a frame.

Probing can never fail the command

Verified end to end, exit code included:

Media assets:
  audio track 1: audio "does-not-exist.wav" → file not found
  view 1 / scene 1 / layer 1: image "corrupt.png" → could not read: Failed to load image 'corrupt.png': unexpected end of file
  view 1 / scene 1 / layer 2: image "https://example.com/remote.png" → remote asset, not fetched
                                (http/https — would risk an unbounded download just to read a header)
EXIT=0

A remote asset is never opened — not the network, not the disk. A missing file is reported before any decode is attempted. An unreadable one carries the exact reason. Every other section still prints.

Why the artefacts gap is refused

Three independent blockers, each sufficient on its own, found by reading the code rather than assumed:

1. The schema cannot carry the field within scope. ResolvedScenario — what render/still/info/batch actually consume — is constructed in exactly one place, include.rs:76-82, outside this change's file list. A field added to Scenario would stay invisible to render.rs. And rustmotion-studio's empty_scenario() would break compiling regardless, a second out-of-scope file.
2. "Do not re-render" is architecturally blocked. Per-frame RGBA buffers only materialise inside the per-format encode loops (h264.rs, ffmpeg.rs, formats.rs), none in scope — the frame is converted to YUV and dropped immediately inside a rayon closure. The one in-scope function able to produce an arbitrary frame is the render; calling it a second time reproduces exactly the cost of the separate rustmotion still invocation this feature is meant to replace.
3. Captions cannot be reused cleanly. cmd_captions shells whisper.cpp (absent from this environment, so unverifiable here) and writes with a bare std::fs::write — not atomic, contradicting the discipline PR fix(cli): stop the helper commands destroying files they do not own #145 and fix(encode): make every output format render the frames it claims #151 established and that the brief required. captions.rs is frozen here, so that cannot be fixed in passing.

An honest path exists for later and is recorded in the issue: extract the thumbnail from the already-produced video file with ffmpeg -ss, which costs zero additional Skia work. It is useless until blocker 1 is resolved.

Two halves — a non-atomic write contradicting an explicit requirement, or a scope breach — would have been a worse result than one gap closed and one refused with reasons.

Verification

• cargo test --workspace: 30 targets, 1136 tests, 0 failures
• cargo fmt --all --check and cargo clippy --workspace --all-targets -- -D warnings: clean
• The 8 examples: 7 validate (the eighth is examples/ferriskey-presentation.json does not pass rustmotion validate (pre-existing on main) #157); rustmotion info exits 0 on all 8, and the new section is absent from every one — none references media, confirming unchanged behaviour for scenarios that do not use it
• One additive Cargo feature (image's gif, so the Gif component's dimensions can be read); Cargo.lock unchanged, the dependency was already resolved elsewhere in the workspace