Fix Firefox crackling during remuxed and transcoded playback

[blurbery]

What I found

I reproduced this against my production server in Firefox using the same affected file. The source was valid stereo AAC at 48 kHz in Matroska, but Matroska exposed a 1/1000 timebase. Silo copied those rounded timestamps into fragmented MP4: AAC packets were always 21.333 ms long while their PTS advanced by 21.000, 21.333, or 22.000 ms. Firefox treats those gaps as missing audio and inserts silence, which is heard as crackling and popping.

This matches Mozilla bugs 1828967 and 1682532. It is a follow-up to the AAC downmix normalization added through upstream PR #820.

What changed

• Firefox web playback now re-encodes AAC audio when an MKV/Matroska source must be repackaged into MP4 or HLS, while still copying the video.
• Every AAC encode now uses timestamp normalization, not only surround-to-stereo downmixes. This covers AAC, DTS, E-AC-3, AC-3, TrueHD 7.1, Opus, Vorbis, FLAC, and other inputs whenever Firefox needs AAC output.
• The AAC transformation recipe is bumped to v4 so old executors cannot silently run the previous byte recipe.
• Native direct play remains unchanged and capability-driven. Other browsers keep their existing codec-copy remux path.
• Resume, rewind, and fast-forward remux reconstruction retain the same normalized audio recipe.

Evidence

Using Silo's exact production remux arguments, the before output contained 21.000/21.333/22.000 ms PTS steps for fixed 21.333 ms AAC frames. With the new audio recipe, every output PTS advances exactly 21.333 ms. The source itself decodes without FFmpeg warnings.

Tests

• Focused planner, remux, audio filter, device-quirk, direct-play, resume, and seek tests pass.
• Broader playback tests selected by AAC|Audio|Remux|FirefoxMatroska pass.
• Added explicit coverage for AAC remux, DTS, intermittent E-AC-3, AC-3, TrueHD 7.1, Opus, Vorbis, FLAC, direct play, zero start, resume, rewind, and forward seek.