Cut release/9.x before the first breaking change lands on main #64

Releases so far are trunk-based: PRs merge into main, and release.yml publishes from an immutable v* tag on main. That stops working once 10.0.0's breaking work (#53 first) starts landing on main while 9.x still needs minor or patch releases.

When: before the first PR with the breaking label (or a silent fix that changes an answer) merges into main. Not earlier. A release branch with nothing to stabilise only adds double merges.

Steps:

1. Cut release/9.x from the last 9.x release tag (v9.1.0 if it's out by then), or from main just before the first breaking merge.
2. Add release/** to the pull_request and push branch filters in .github/workflows/dotnet.yml and .github/workflows/pr-hygiene.yml. Today both only run for main, so a PR into the release branch would get no CI at all.
3. Protect release/** the way main is protected: up to date before merging, and the required checks Test, Integration, Pack and Consumer smoke test.
4. Check release.yml: it publishes from any v* tag, so a v9.x.y tag on release/9.x works. The tag must still match Directory.Build.props on that branch.
5. Decide how fixes move between branches. The usual way is to fix on main first and cherry-pick to release/9.x, with the PR into the release branch linking the original.
6. Write it down in CONTRIBUTING.md and AGENTS.md.
7. Mind the tracking: Closes #n only closes issues when a PR merges into the default branch. Close an issue that is fixed only on release/9.x by hand, or link it from the matching main PR.

Done when release/9.x exists with CI and protection, and the first breaking PR can merge into main without blocking a 9.x release.