RecodeAudioMode::Encoder is still stringly-typed, so --recode-audio got none of #642's protection

[crippledgeek]

Follow-up to #642 (closed via #647).

RecodeAudioMode::Encoder { name: String } (rdlp-types) was deliberately left unmigrated: its value is ambiguous by design — it may name a codec or an encoder, and resolve_audio_encoder tries both.

Why it matters

The result is an asymmetry in user-facing protection: --video-encoder is now VideoEncoderName and fails at parse with an actionable message, while --recode-audio=<encoder> is still a raw String reaching container_supports_audio_codec / resolve_audio_encoder as &str (recode.rs:477, :495). The audio vocabulary got none of #642's guarantees.

The design question

A single MediaName<K> does not fit a value that is legitimately either vocabulary. Options worth weighing explicitly rather than assuming:

• An enum { Codec(CodecName), Encoder(AudioEncoderName) } resolved at parse.
• A MediaName<K> with a new kind meaning "codec-or-encoder", with retag used at the resolution point.
• Leave it a String and validate at the boundary only.

Note #645 is open on this same option's explicit-vs-default semantics; whoever takes this should read it first.

Acceptance

• A malformed --recode-audio value fails with a clear message rather than deep in FFmpeg.
• The codec-or-encoder ambiguity is expressed in the type or explicitly documented as deliberate.
• Wire/config representation unchanged (round-trip test).