"Name the audio demuxer from the file extension and cap stream probing"

Related to #4880. Depends on !5488 (merged)

Follow-up to the mp3 question on !5488 (merged): after avformat_open_input, an mp3 stream has its codec id, but sample rate and channel count arrive only with the first decoded frame; the scan cannot be skipped for it, only bounded.

FFmpegDecoder::open() now names the demuxer from the file extension (wav, mp3, ogg/opus, flac); this lets avformat_open_input skip content probing. It caps probesize (64KB) and analyzeduration (200ms of media; the cap must cover a few frames so mp3 completes its parameters under it) on that attempt. If the hinted open fails, or a lenient demuxer accepts mislabelled data but yields empty codec parameters (mp3 does this when fed flac bytes), it rewinds the VFS stream and retries the current fully probed path. Mislabelled files (an mp3 shipped as .wav, which mods do ship) behave exactly as today.

The decoder's custom IO used a zero-size avio buffer; the probed path tolerates that, but a named-format open reads through the buffer directly and fails immediately. The open now allocates a real 8KB buffer, which the fallback path shares.

Same rig as !5488 (merged) (i5-8365U, NVMe, ffmpeg 8.1.2, cold cache per file):

• music mp3 init 1.34 -> 0.75 ms p50; voice mp3 0.47 -> 0.29 ms p50
• in-game (Sadrith Mora save, 180 s): open p50 0.36 -> 0.04 ms (wav 0.36 -> 0.09 ms); the 9-50 ms one-off storage wake-ups remain in both runs, they are storage power management and out of scope (#4880)
• emulated slow storage (30 ms open / 8 ms read): voice init p95 56 -> 40 ms; p50 stays at ~39 ms, the medium's own open plus first-read cost, which no change at this layer reaches
• modded validation: Quest Voice Greetings' 1828 generated voice mp3s all take the capped path, init reads p50 16.5KB / max 49KB

Scope: this trims the CPU floor and the probe reads for mp3.

• I have read the CONTRIBUTING guidelines
• My code runs locally
• My code passes CI on my fork