release: make the release flow land commits on main so 'Closes #' lines actually process

[Hmbown]

What happened (v0.8.55, confirmed 2026-06-09)

v0.8.55 was cut and tagged from a release branch, but the commits never reached main — the tag (b6604b43) was pushed while main stayed at the pre-release web/CI commits. Consequences observed tonight:

1. The Closes #2906/#2907/#2910/#2912/#2913 lines in commit c13bc248 never processed (GitHub only honors close-keywords when commits land on the default branch). The issues sat open against a shipped milestone until a manual sweep.
2. PR v0.8.55 — Together AI provider + experimental OpenAI Codex (ChatGPT) provider #2916 (the release PR) sat open as "unmerged" even though the release had shipped from its branch.
3. The repo's own audit tooling mis-read release state ("main @ b6604b4" was true only on the machine that cut the release).

It took a manual fast-forward push of main tonight (9463266cb..356b632b8) to reconcile, which auto-merged #2916 and processed the closes.

Fix

Pick one and encode it in the release runbook/script:

• Preferred: the release script merges the release branch into main through the release PR before tagging — tag points at a commit reachable from main, closes process, PR shows merged.
• Fallback: if tagging from a branch is ever necessary, the script must (a) fast-forward/merge main immediately after, and (b) run an explicit gh issue close sweep for the release's 'Closes' list.

Acceptance

• The v0.8.56 release lands on main via PR before/at tag time; its 'Closes #' lines process automatically; no open release PR is left behind.
• The runbook (docs/ or scripts/release*) documents the order of operations.

Related: #2642, #2643 (asset/tag verification hardening, both in v0.8.56).