LTX-2.x is the one video family here with an audio VAE and a vocoder, so its
output is LTX2PipelineOutput(frames=..., audio=...) -- audio generated jointly
with the frames and therefore actually in step with them. Only `frames` was
read, so every LTX render came out silent and the only way to get sound was to
generate some separately with another model and mux that on top, which does not
match the picture. The generated track is now muxed in BEFORE the other
post-processing steps, because every one of them re-encodes the frames and the
track belongs to these exact ones.

`add_audio` becomes tri-state so "say nothing" and "say no" differ: unset keeps
what the model generated, false gives a silent video, true runs the older
separate-generation path. It defaulted to False, which cannot be told from an
explicit false -- so a straight default would have dropped the soundtrack. None
is falsy everywhere False was, so existing callers are unaffected.

Found while testing it: _has_audio tried `import av` under a bare
`except: return False`, and PyAV is in no main requirements file -- only the
isolated LongCat venv's. On an install without it EVERY file answered "no
audio", and because it gates _mux_original_audio, a clip's own sound was
silently dropped from every upscale and interpolate. The audio was there,
nothing could see it, and nothing said so. ffprobe cannot be missing the way
PyAV can, since ffmpeg is what does the muxing, so it is the fallback, and a
failure of both is logged instead of reported as silence.

Also: one of my own tests asserted a minimum number of ffmpeg progress reports.
`-progress` emits on a time interval, so a small encode can finish having
emitted a single block -- it passed alone and failed under the full suite. It
now asserts what is guaranteed: frames counted, counted upward.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC