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.

Conflict resolution

main was merged into this branch (c74b271). The only release-side change was #5069, the backport of #5027, which main already carries in full. Every conflict resolves to main:

• rs/moq-net/src/ietf/subscriber.rs: keeps main's open_group guard with resume.is_none(), which the backport dropped because release has no resume path. Taking release's side would drop a valid clear FIRST_OBJECT on a resumed subscription. The test helpers keep main's Encoder and moq_net_sim::test harness.
• js/net/src/ietf/subscriber.ts: main's Reader value import, which main's newer code uses.
• js/net/src/ietf/subscriber.test.ts: keeps main's added draft-16 mid-group test; both fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027 tests are already on main.

The merged tree is identical to main, so this PR only records release ancestry. #5072 is not included; a later back-merge carries it.

Impact

• No public API or wire change.

(Written by Claude Opus 5.5)

[kixelated]

ITERATE (reviewed 5d9d64ae0ffcea24b5ee8ca38518554691aeafe2)

What this is

Back-merge of release → main carrying the #5069 backport of #5027 (fix(net): accept a clear FIRST_OBJECT that starts at object 0). Not a clean release-plz version bump: one substantive commit, no CHANGELOG/version files in the unique diff. Branch tip is identical to release; GitHub reports CONFLICTING / dirty vs current main (≈464 commits behind).

Blocking

1. Cannot merge until conflicts with main are resolved (PR body already says: merge main into merge/release-into-main and resolve there; merge commit only, never squash).

2. Conflict resolution risk in rs/moq-net/src/ietf/subscriber.rs: main already has fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027's full fix, including the resumed-subscription exception:

if !header.flags.first_object
    && !fill.read().outstanding()
    && resume.is_none()
    && first.is_none_or(|first| first.id != 0)

The release backport deliberately dropped resume.is_none() (and its comment) because release had no resume path. Taking the release side of that hunk would regress main: a clear FIRST_OBJECT on a resumed subscription that starts partway through would be dropped even when valid. Prefer main's open_group condition (keep resume.is_none()).

JS (object.ts comment, subscriber.ts peek, tests) already matches on main in substance; resolve those in favor of main (or either identical side) — no behavior change expected.

Non-blocking

• After a correct resolve, this back-merge should be a no-op (or near no-op) for the FIRST_OBJECT logic; the useful work already landed via fix(net): accept a clear FIRST_OBJECT that starts at object 0 #5027 on main and fix(net): accept a clear FIRST_OBJECT that starts at object 0 (backport #5027) #5069 on release.
• CI release workflows still pending when reviewed; not a merge blocker once conflicts are fixed and checks are green.

Verdict

ITERATE — merge main into this branch, keep main's resume.is_none() guard when resolving subscriber.rs, then merge with a merge commit (never squash).

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