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]

MERGE

Reviewed head d6d33681d22a9c5fa6f06f5c3bf0fb2f10432980 (identical to current release tip; this is the #4738 merge commit d6d33681 back into main).

What this does: Automated Back-merge of release → main so trunk picks up the publish-only-from-release workflows, docs//release#… pin wording, and the back-merge machinery, and so the next cut's merge base advances. Body + auto-merge are correctly set to merge commit, never squash.

Blocking

None.

Non-blocking

1. Tip drift vs current main is expected and should resolve cleanly. Blob-compare of this head vs main tip shows nearly all of ci: publish only from release #4738 already on trunk (via chore: trunk is main, releases ship from release #4737 / ci: release-brew accepts only this repository's tag pushes #4740 / prior lands). Remaining tip-level deltas are stale release-side names (libmoq, comment still says main and dev in alert.yml) vs main's newer moq-c / main and release. Three-way merge is MERGEABLE; those hunks should keep main's side. Not a regression risk from this PR's own commit.
2. CI still settling at review time (Check / Test / OBS / WASM / etc. pending or in progress; nothing failed). Auto-merge is already queued (merge method by moq-bot). mergeStateStatus was blocked/unstable on required checks — wait for green, don't squash-land by hand.
3. Cross-PR: Does not re-open ci: publish only from release #4738 residuals (go/kt/swift workflow_run still use event == 'push' without brew's extra head_repository.full_name check — accepted there; brew already matches on main via ci: release-brew accepts only this repository's tag pushes #4740). Trunk required_linear_history / quest: branch flip drops linear history on trunk #4730 Sequence gap remains outside this PR.

Script / workflow spot-check (no new issues)

• sh/gh/back-merge.sh: ahead-by short-circuit, create-or-merge-into merge/release-into-main (no reset over hand-resolved conflicts), same-repo find_pr, --auto --merge --match-head-commit — correct.
• .github/workflows/back-merge.yml: push/workflow_dispatch on release, cancel-in-progress: false, owner gate, app token so the PR triggers Check/Test — correct.
• Release workflow flips + head_sha pins match what was MERGEd on ci: publish only from release #4738; no back-merge conflict resolution or content drift vs release.

Summary: Safe to land as a merge commit once required checks pass. Purpose is history/merge-base hygiene more than new trunk file content.

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