chore: merge release into main

[moq-bot]

Carries what release published (versions, CHANGELOGs, backports) back to trunk. Opened by the Back-merge workflow.

Merge with a merge commit. Never squash. A squash leaves the merge base at the last cut, so the next back-merge conflicts. On a conflict, merge main into merge/release-into-main and resolve it there.

[kixelated]

Resolved at 012e4442. The tree is identical to main (0 files changed), so this PR only carries history, including #4829's commits:

• rs/moq-net/src/lite/subscriber.rs: kept main. fix(net): a relay resuming mid-group asks upstream for the group's head #4829 is release's backport of fix(net)!: resume route changes by reading the routes' copies; a path is one broadcast #4741's widen_frame_bounds, which main already has.
• rs/moq-net/tests/catalog_resume_snapshot.rs: left off main. Its lite-07 peer-fetch variant fails on main (quest/m1/lite07-head-fetch-arrival.md, quest(m1): retracted demand release and lite-07 fetched heads #4830); that quest lands the test with its fix.

moq.pro needs this merged: Nix fetches the pinned moq submodule commit only from upstream main.

(Written by Claude Opus 5.5)

[kixelated]

Automated review of head 55f5e7202e5d08e83599db0e711bf06bdb4391bf

This back-merge carries #4829 (relay widens a mid-group SUBSCRIBE start to the group head, plus tests/catalog_resume_snapshot.rs) from release into main. GitHub reports it as conflicting, and the obvious way to resolve it would bring back a behavior main deliberately dropped.

Blocking

1. rs/moq-net/src/lite/subscriber.rs TrackServe::widen_frame_bounds: keep main's side.
On main (around line 3450) the head widening is already there, but it's gated on !version.has_largest(), so it applies to lite-06 and not lite-07. On lite-07 the SUBSCRIBE_START carries the largest position, so set_live is set from it (around line 4266). Release's hunk widens unconditionally inside the has_frame_bounds() branch. That's fine on release, which has no has_largest, but on main it would also widen lite-07. That throws away what the largest position is there for, and it hides the cache bug that quest/m1/lite07-head-fetch-arrival.md (#4830, just merged) says should be fixed in TrackState::insert_group_request/claim_sequence, not by widening. The quest says this directly: "Widening on lite-07 too would hide the bug at the cost of what the largest position is for; the fix belongs in the cache." So when resolving, keep main's gated block and drop release's added line and its comment. The comment is also wrong on main ("No SUBSCRIBE_OK here reports the largest position").

2. The unit-test hunk: drop release's side.
Release renames frame_bounds_survive_on_a_lite06_peer to frame_bounds_start_at_the_group_head_on_a_lite06_peer. Main already replaced that test with a_mid_group_start_survives_only_where_the_answer_has_the_largest (around line 2174), which asserts a lite-06 start of 0 and a lite-07 start of 3. Taking both would duplicate coverage. Taking release's alone would lose the lite-07 assertion.

3. tests/catalog_resume_snapshot.rs will merge cleanly but should fail on main for moq-lite-07-wip.
VERSIONS includes moq-lite-07-wip. Once main's lite-07 gate applies, fresh_reader_gets_snapshot_after_peer_fetches_head for lite-07 is exactly the repro in lite07-head-fetch-arrival.md, which is still open. I also expect ..._after_mid_group_resume and ..._after_local_mid_group_resume to fail for lite-07, since the relay's upstream keeps (G, 1) and holds a headless G. That's the stall #4829 describes. I can't run it from here, so please confirm locally. Either way, don't "fix" the red Test job by re-adding the widening. Instead, run the mid-group variants only for the versions without the largest position (and moq-transport), and track the lite-07 rows as a separate #[ignore]d test that links the quest, so whoever fixes the cache can un-ignore it.

Non-blocking

• CI (Check/Test) is running on the branch head, which is release code, because a conflicting PR has no merge ref. A green run now says nothing about main. Wait for the run after main is merged into merge/release-into-main.
• tests/rejoin.rs (test(net): a mid-group rejoin keeps the relay's copy whole #4828, now on main) covers nearby ground: a mid-group rejoin keeps the relay's copy whole. No conflict, just two files that are worth reading together.

Resolve as the PR body says (merge main into merge/release-into-main, never squash), using main's gate plus the trimmed test matrix. After that, it should be ready.

Verdict: ITERATE

This is an automated review, not the maintainer's decision
(Written by Grok)