Bring the release runbook up to date, protect release branches, and fix main's preview version

[ChrisonSimtian]

Brings the release runbook in line with what the project actually ships, and captures the release-branch protection config in the repo. Everything here came out of cutting v10.4.0-rc.4. Docs + one config file; no product code.

1. Release branches are protected by a ruleset

release/v10.4 ran unprotected from its cut on 2026-07-21 until today — anything could be pushed straight to the branch that fires production releases. The on-demand cut (ADR-0007) has no protection step attached, and the runbook's step 3 pointed at scripts/release-branch-protection.json — a file that never existed.

Now a pattern-based ruleset on refs/heads/release/** (19766406), so every release line is protected the moment the branch exists — release/v10.4 now, a release/2027 cut later, with no per-branch step to forget. Mirrors main's profile; repo admins bypass, matching the tag ruleset. Payload committed at .github/release-branch-ruleset.json (in .github/, not scripts/ — it's GitHub config, not tooling) with the PUT command to re-apply after an edit.

2. The runbook described a line that doesn't exist

Every example named release/2026 and v2026.1.X, while the line actually shipping is release/v10.4 at 10.4.0-rc.N — so no command was copy-pasteable. The channel table also claimed previews were 2026.1.0-preview.<height> when main's version.json says 10.0.0-preview.{height}.

Documents release/vMAJOR.MINOR alongside release/YYYY (the pipeline matches both), adds a "lines live right now" block as the one place to keep current, and retargets the examples. ADR-0004/0007 CalVer intent is unchanged — a year cut substitutes branch and tag and works identically.

3. Two traps that cost time on rc.4

• --ref on a workflow_dispatch selects the workflow definition, not just the source to pack. Dispatching against the default branch runs main's pipeline — which differs from the release branch's whenever a fix isn't forward-ported yet — and still pushes to nuget.org.
• A green release run is not evidence packages shipped. Every publish job is conditional, so a bad condition skips it while the run reports success. That was true of all three jobs on the dispatch path (fixed in #567). Adds the commands to check what actually ran and whether the version resolves.

4. Prerelease numbers are a manual counter

The rc number is pinned literally in version.json rather than derived from {height}, which would have jumped rc.3 → rc.23. That makes bumping manual, and forgetting means republishing an existing version — which --skip-duplicate swallows silently.

5. main's preview lane moves onto the 10.4 core

main advertised 10.0.0-preview.{height} while the line actually shipping is 10.4.0 — so the trunk published previews numbered below the branch cut from it. 10.0.0 was never a target anyone intends to release; it was left behind when the 10.4 line was cut. Now 10.4.0-preview.{height}.

Two consequences, both verified:

• The height resets, so previews restart at 10.4.0-preview.1 rather than continuing from 10.0.0-preview.34. Nothing regresses — 10.4.0 sorts above 10.0.0, so the new previews still supersede every published one.
• 10.4.0-preview.N sorts below 10.4.0-rc.N, which is right while main is the trunk 10.4.0 stabilises from. Once 10.4.0 goes GA, main needs rolling to the next core (10.5.0, or the CalVer major) or its previews start reading as older than the released package despite carrying newer code — the same roll-forward the yearly-cut runbook already describes.

Ordering checked against SemVer 2.0 precedence: 10.0.0-preview.34 < 10.4.0-preview.1 < 10.4.0-rc.4 < 10.4.0, and 10.3.47 < 10.4.0-preview.1.

Corrections to existing claims

Two things the protection docs asserted that aren't true:

• Stale approvals are not dismissed on new commits (dismiss_stale_reviews: false).
• Squash merge is not disabled by repo setting — only plain merge commits are (allow_squash_merge: true). So "rebase only" rests on convention, not enforcement. Worth closing separately if you want it enforced; squashing a promotion would collapse reviewed commits into one opaque commit.