fix(playback): stop Firefox AAC crackle after audio transcode

[blurbery]

What changed

Firefox no longer receives irregular packet timestamps when Silo converts multichannel audio to stereo AAC.

• Added bounded timestamp compensation (aresample async=1) to the existing surround-to-stereo AAC recipe.
• Kept the source clock and first packet timestamp intact; this does not force a new zero point or change the video-copy route.
• Bumped audio_to_aac from recipe version 2 to 3 so an older transcode node cannot claim the new byte recipe.
• Updated the capability smoke probe and focused remux, transcode, registry, node-offload, resume, and seek tests.

Root cause and evidence

I reproduced this on the signed-in production web UI with Firefox 154. It affected both DTS-to-AAC and AAC-to-AAC conversion. The source codec was not the common factor, and the session logs showed no buffering, HTTP failure, corrupt frames, or server-side decoder error.

The generated AAC packets had fixed 21.333 ms durations but inherited sub-frame timestamp jitter from the source:

• DTS-to-AAC produced several short and long PTS steps instead of one continuous AAC cadence.
• AAC-to-AAC produced steps around 21.0–22.0 ms and one 25.980 ms jump.

With the corrected recipe, both sources produce only 21.333/21.334 ms steps, which is the expected rounding for 1,024 AAC samples at 48 kHz.

I also captured decoded PCM from the same failing production position in a clean Firefox profile. Across the same six-second window, unintended zero-run boundaries dropped from 27 to 5 and the largest adjacent-sample delta fell from 0.1035 to 0.0936. RMS level and decoded sample count remained equivalent. Chromium's HLS route was already clean, which is why this was visible only in Firefox's progressive fMP4 route.

This is a shared timestamp-correctness fix rather than a Firefox user-agent workaround. It preserves video stream copy, current quality, existing downmix loudness/headroom, HLS behavior, and browser fallbacks.

Saved-position resume and new streams created after a forward or rewind seek use the same corrected AAC cadence while retaining their requested seek anchor. Direct play and codec-copy remux paths do not receive the audio filter and remain unchanged.

Validation

• go test ./internal/playback -run 'Test(BuildRemuxArgsBoostsOnlySurroundToStereoAAC|AppendAudioArgsBoostsOnlyEncodedSurroundToStereo|ProbeTransformationRegistryV3RequiresVersion3AudioFilterGraph|TransformationRegistryWithAdvertised|PlanPlaybackV3AudioAdaptationOffloadsToHLSRemux|PlanPlaybackV3AudioOnlyConvertsUnsupportedCodec)$'
• go test ./internal/playback -run '(Audio|Remux|Transformation)'
• go test ./internal/playback -run 'Test(BuildRemuxArgsNormalizesAACAcrossSeekAnchors|BuildRemuxArgsBoostsOnlySurroundToStereoAAC|AppendAudioArgsBoostsOnlyEncodedSurroundToStereo|PlanPlaybackV3DirectPlayNeverConsultsNodeCapabilities|PlanPlaybackV3DirectPlaysH264ConstrainedBaselineWithoutTranscoding)$'
• Clean Firefox 154 profile: real DTS-to-AAC before/after PCM comparison.
• Production FFmpeg/FFprobe: real DTS-to-AAC and AAC-to-AAC packet-cadence comparisons.
• Real-source timestamp checks at initial playback, a saved 2,201.111-second resume point, a 600-second rewind anchor, and a 2,800-second forward anchor. Every corrected run contained only 21.333/21.334 ms AAC steps.
• Direct-play planner tests and a codec-copy remux assertion confirm that streams which do not require AAC conversion are untouched.
• Current upstream was checked read-only; it still carries recipe version 2 without timestamp compensation.

The complete local playback-package run reached unrelated sandbox-dependent NVENC/VideoToolbox probe failures; the audio/remux subset passed. GitHub Actions is the full supported-environment gate for this branch.

Related issue: N/A — narrow fix

AI Disclosure

• Tool(s): OpenAI Codex desktop
• Model(s): GPT-5
• Involvement: AI-assisted — I identified the Firefox-only crackle, confirmed it with both AAC and DTS sources, directed the investigation, and reviewed the measured behavior. Codex assisted with production diagnostics, Firefox PCM capture, code changes, tests, and drafting.
• Adversarial review: The complete diff was reviewed against progressive and HLS execution, audio-only and non-downmix routes, mixed-version transcode nodes, video-copy seek alignment, and Firefox's existing HLS fallback. Synthetic flag changes were rejected because they did not reproduce or improve the defect; the final change was kept only after real-source packet and PCM measurements showed the correction.

Checklist

• I read and can explain the complete diff.
• This pull request addresses one concern.