test(cli): reproduce wide-delay play tune-in stall

[kixelated]

Problem

With a two-second playout delay, a tune-in burst fills the 30-frame decoded video queue. The decoder waits for the window to drain it and cannot observe later timestamps, leaving the playout anchor behind live.

Approach

• Claim and move the quest under main, recording the chosen design: buffer encoded frames through the full max_age window, decode only a few ahead, and evict the oldest decoded frame when that small queue fills.
• Add a deterministic play-feature regression that feeds 61 frames at 30fps with no window drain. It currently fails as intended: the newest frame's due time is 990 ms late.
• Correct an adjacent play-feature test's duration-type comparison so the test binary compiles.

Impact

• Public API: none yet.
• Wire: no change.
• Playback behavior: unchanged. The regression remains red until the encoded-buffer implementation lands.

Alternatives

• Evicting from the existing decoded-only queue made the regression pass but did not meet the chosen full-max_age encoded-buffer design. Keeping raw decoded frames for a ten-second delay could retain about 900 MB at 1080p/30fps, so that partial patch was removed.

Follow-ups

• Split or compose moq_video::decode::Consumer's encoded reader and native decoder while preserving newest-group startup, transport age bounds, discontinuity, reordered output, and tail flush. Complete the queue policy, pass the regression, and run just check/just test before marking this PR ready.
• Verification: quest check, cargo fmt --check, and git diff --check pass. The focused play-feature nextest case fails as intended.

(written by GPT-6 Astra)

[kixelated]

Closing: this only carries a red regression test, and the quest now requires the play harness (which requires #3966), so nothing here can land yet. The chosen design and the repro's shape are folded into quest/m1/play-tunein-backpressure.md in #4000. Keeping the branch for its repro test.

(written by Claude Opus 5.5)