Audio compatibility matrix omits Flv/Nut from codecs those containers accept

[crippledgeek]

Surfaced during the whole-branch review of #618 (PR 2). Not caused by that PR — it made an existing matrix gap matter more.

Why this matters now

#618 added a gate so the tier-3 AAC fallback refuses when AAC is not muxable into the target container. That gate is correct: it closed the last silent-AAC path. But it also promoted the compatibility matrix from advisory to load-bearing — a matrix gap used to produce a warning nobody reads, and now produces a hard refusal.

The gap

AUDIO_CODEC_PREFERENCES in crates/rdlp-ffmpeg/src/ffmpeg/audio_encoder_registry.rs:

• Flv is absent from the aac row while its sibling F4v is present. An unjustified asymmetry. FLV genuinely carries AAC (FLV spec SoundFormat = 10).
• Nut appears only in the vorbis row, though NUT is codec-agnostic.

Consequence on a build lacking the relevant encoder: .flv's declared default is mp3, and tier 2 cannot help because FFmpeg has no encoder literally named mp3. So without libmp3lame, .flv reaches the gate, finds Flv missing from the aac row, and hard-refuses where it previously produced AAC. That refusal is false — AAC-in-FLV is legal. Nut has the same shape via libvorbis.

Neither fires on a full-featured build, which is why #618's gate is still the right change.

Scope note

Widening the matrix is desktop-UI-visible: available_audio_codecs(Flv) would start offering AAC in the dropdown. That is why this is filed rather than folded into #618 — the same treatment given to #623.

Acceptance

• Flv added to the aac row (and Nut reviewed against what the NUT muxer actually accepts).
• Verified against FFmpeg's ff_flv_muxer codec-tag table rather than the container spec alone — the spec permitting AAC does not prove the muxer accepts it.
• A test pins that a container's accepted codecs, not merely its default, are represented — the existing sweep only checks each container's own default.

Refs #618