feat(moq-hls): list a durable archive timeline without the live window

[kixelated]

Completes the Archive HLS window quest.

moq-hls now lists a durable timeline's whole retained range instead of trimming it to --window, so a replayed recording no longer needs a server-wide --window raised past its length (which also inflated segment max-age and DASH timeShiftBufferDepth for every live broadcast on the server).

Decision: the catalog archive entry says the timeline is authoritative

A broadcast's timeline is treated as authoritative when its catalog archive entry names a store and no replay path. The draft already defines both: with a store every advertised range is durable, and without replay the timeline lives on the catalog's own broadcast. So those ranges stay FETCHable from this broadcast until the timeline pops them, and only those pops trim the playlists.

Alternatives considered:

• A per-broadcast option on Broadcaster: puts the policy in every embedder and needs a side channel for the stock moq export hls server to learn which broadcasts are recordings.
• A separate server for recordings: operational overhead, and one origin can hold both kinds.

The catalog signal needs no new field, no new API, and keeps the policy in the protocol's own declaration.

Derived values

• HLS: a durable timeline lists every retained record; DVR pops still trim it.
• DASH: timeShiftBufferDepth (and the suggestedPresentationDelay bound) is the listed span for a durable timeline, and the configured window otherwise.
• HTTP: segment Cache-Control: max-age still comes from --window, so it stays capped for every broadcast.

API and wire impact

• Public API: none. export::Config::window keeps its type; its doc now says what it doesn't bound.
• Wire / catalog: none. This reads the existing archive.store and archive.replay fields.
• Behavior: a catalog whose archive entry has a store and no replay gets unbounded playlists. No publisher in this repo sets store yet; a replay's embedder sets it on the catalog it supplies.

Tests

a_durable_timeline_lists_past_the_window replays 24s of recording under the default 16s window: the durable entry lists segment 0 with EXT-X-MEDIA-SEQUENCE:0 and timeShiftBufferDepth="PT24.000S", while a live-style entry and an entry with a replay path keep the window. The existing DVR test now runs against a durable entry, so timeline pops still trim it.

Notes

• just check passes tests and lint for this diff but fails _publish-test on a pre-existing line issue from feat(cli): record and replay archives with export archive / import archive #4113: rs/moq-cli/Cargo.toml has moq-json = { workspace = true } as a dev-dependency of a published crate. Left for the line so this PR stays focused.
• moq import archive publishes no live catalog group, so the stock server still needs an embedder to supply the replay's catalog (as the tests do). Stamping store on that catalog belongs with that follow-up.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-25T17:06:35.655273Z	821c89f	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[kixelated]

Squash-merged onto quest/m1/archive/README as 25a852d. No commits pushed.

A catalog archive entry with a store and no replay path lists the whole retained timeline; --window still bounds live playlists and segment max-age. Test was green. Check was still running and is not required on this base.

Follow-ups, unchanged: the stock moq import archive path still needs an embedder to stamp store on the replay catalog, and _publish-test still fails on the pre-existing moq-json dev-dependency from #4113.

(Written by Grok 4.7)