mux: suppress adjacent identical PSI runs

[kixelated]

Problem

Aligned keyframes from several video PIDs can place identical PAT/PMT runs back to back. Three video PIDs at 25 Mb/s fill the PAT transport buffer to 533.92 bytes, exceeding its 512-byte T-STD capacity.

Approach

Group table runs in mux order and suppress an identical run only when the same layout flush would place it immediately after its predecessor. Preserve changed tables and repetitions separated by media, which are distinct tune-in points. Constant-rate slots replace removed packets with nulls; unpadded slots gain no padding. Continuity counters are assigned after layout, so suppression cannot create counter gaps.

This implements the narrower approach proposed on #5207, with system-buffer regression coverage across 3/4/8 video PIDs and 25/50/100 Mb/s. The regression fails before the fix. A CI-wired benchmark sweeps 1/4/16/64 PIDs independently of 1/16/128 packets per PID.

All 401 TS regressions pass, including the existing AAC tune-in check and the previously failing system-buffer test. The 12-case benchmark comparison below measures this correctness fix on a shared host; changes range from about 10% faster to 4% slower, without claiming a universal speedup. The changed-version same-flush regression passes too. Final Nix validation passes: just check, just test ts --headroom, just test interop --all (all languages, refusals, browser close and finite tails), and quest check (454 documents).

Video PIDs	Packets/PID	Before µs	After µs
1	1	0.475	0.448
1	16	0.697	0.691
1	128	1.829	1.838
4	1	0.805	0.727
4	16	1.749	1.621
4	128	6.927	6.744
16	1	1.782	1.727
16	16	5.962	6.090
16	128	30.582	31.842
64	1	7.889	7.141
64	16	51.298	46.049
64	128	350.210	313.610

Impact

• Public API: none; slot padding remains private implementation state.
• MoQ wire/catalog: unchanged.
• MPEG-TS output: adjacent duplicate table runs are removed, while changed tables and distinct tune-in points remain. Constant-rate packet counts and PCR positions remain unchanged.
• No dependencies or versions change.

Alternatives

Keeping tables only once per slot breaks the AAC tune-in contract. Spacing or dropping distinct table versions would require a different scheduling policy. This change only removes copies that introduce no new tune-in point.

Follow-ups

Keep this PR draft and retain the quest: the narrow implementation does not establish the broader system-buffer promise. An independent probe of the production layout found PAT peaks of 518.88 bytes for four equal 100-packet video units at 25 Mb/s, and 1022.72 bytes for eight equal 10-packet units. These are distinct tune-in table runs separated by media, so adjacent-copy suppression correctly preserves them but cannot pace them.

Recommend finishing rate-aware PSI pacing together with media admission and decode-deadline coordination before claiming the full invariant. The alternative is explicitly narrowing this quest to adjacent-copy suppression and planning pacing separately. Inserting padding beyond the slot budget or deleting distinct tune-in copies would violate existing contracts. No failing check is relaxed; the original regression and these broader counterexamples are distinguished.

(Written by GPT-6 Astra)

[kixelated]

Scope decision from the maintainer on #5321: quest/m1/tstd/psi-runs.md stays the full system-buffer guarantee, with pacing in scope. Its plan now models the PAT and PMT in one shared 512 B TBsys per program (H.222.0 2.4.2.3), so the per-PID PAT figures here understate the fill: two back-to-back pairs already reach about 729 B at 25 Mb/s. Changed table versions and distinct tune-in runs are paced rather than left bunched, building on the PMT pacing #5220 is adding, and compliance.py gains a hard TBsys check. This PR stays a draft until that pacing lands.

(Written by Claude Opus 5.5)