Release-branch model & multi-channel CD

Shift the project from "every merge to main = release" to a release-branch model with tag-triggered, multi-channel CD.

Driven by RFC #267 — design discussion, open questions, work breakdown.

What changes

main becomes the integration trunk — what's in main is what's currently stable for the active major. Merging to main no longer publishes.
release/vN branches are the release channels — release/v11 cut from main at the v11.0.0 ship point. Eventually release/vN.M for minor lines.
Tag-triggered publish — pushing v11.0.4 (or similar) to release/v11 fires the publish workflow. Merging to a release branch only stages commits.
Hotfix flow via cherry-pick — fixes land on main first, then cherry-pick to release/vN and tag.
Multi-channel CD via GitHub Environments — three environments keyed by channel (nuget-org, github-packages, github-releases), one publish workflow producing three deployment records. nuget-org gets an approval gate (irreversible).
Documentation in CONTRIBUTING.md and docs/ — contributors and AI agents both need to understand the new flow.

This work cuts across all major versions — it's process/infrastructure, not feature work. Related to but distinct from:

#4 CI roadmap — broader CI restructuring.
#8 Continuous Delivery Vision — v13 long-horizon CD/release thinking.
#263 CHANGELOG vs GitHub releases — auto-generated release notes question intersects here.

This milestone is the concrete first step toward a stable CD shape, scoped tightly to the branching + publish-trigger restructure.