fix(encode): reject a codec the container cannot hold, before rendering

[LeadcodeDev]

Closes #191.

What

$ rustmotion render -f c.json -o out.mp4 --codec prores
[vf#0:0 @ 0x...] Task finished with error code: -22 (Invalid argument)
[out#0/mp4 @ 0x...] Nothing was written into output file, because at least one
                    of its streams received no packets.

The codec/container pair was never validated: rustmotion rendered every frame, handed the result to ffmpeg, and passed ffmpeg's internals through. No output file was produced.

--codec prores is the documented recommendation for dark gradients (CLAUDE.md) and .mp4 is the default extension, so the two together are a natural mistake — and the cost of discovering it was a complete render.

After

$ rustmotion render -f c.json -o out.mp4 --codec prores
Error: codec 'prores' cannot be written into a .mp4 file — use -o <file>.mov,
       or drop --codec for H.264

$ rustmotion render -f c.json -o out.mov --codec prores    # 28 KB, written

How

check_codec_container is a pure lookup in encode::video::formats, called before the first frame in both cmd_render and cmd_watch. Design choices worth flagging:

• An unknown codec passes through. Second-guessing ffmpeg would block combinations it supports; the check only refuses pairs it knows are wrong.
• gif / png-seq / raw are left alone — they have their own encode path and never reach the ffmpeg muxer.
• The message names the working container rather than restating the failure.

Tests

Five, no ffmpeg needed: prores/mp4 refused with .mov named, the documented pairs accepted, vp9/mp4 refused, unknown codecs passed through, own-path containers untouched.

cargo test --workspace green, cargo fmt --check and cargo clippy --all-targets -- -D warnings clean.