Refactor release.yml: tag-triggered, multi-channel via environments

[ChrisonSimtian]

Sibling of milestone #13. RFC #267.

What

Rewrite .github/workflows/release.yml from its current stopgap shape (workflow_dispatch only) to the real model: tag-triggered, three deployment records, one per environment.

on:
  push:
    tags:
      - 'v*'

Plus a guard that the tag is pointing at a release/v* branch (defensive — prevents accidental publishes from tags pointing at random commits).

Acceptance criteria

• Trigger is push.tags: v*.
• Job validates that the tagged commit is reachable from a release/v* branch (git branch -r --contains $GITHUB_SHA | grep -E 'origin/release/v[0-9]+').
• Test + Pack run once (shared artifacts).
• Three parallel publish jobs, each with environment: declared:
  • publish-nuget-org (env: nuget-org, requires approval) → dotnet nuget push ... nuget.org
  • publish-github-packages (env: github-packages) → dotnet nuget push ... github.pkg
  • publish-github-releases (env: github-releases) → gh release upload (or actions/upload-release-asset)
• Each publish job creates a deployment record (automatic via environment: keyword).
• Nuke.* transition-shim push (currently inline at the bottom of the workflow) is folded into publish-github-packages — same destination.
• On nuget-org publish failure: job retries with --skip-duplicate semantics so partial successes are recoverable.
• workflow_dispatch trigger preserved as a backup with a clear in-file comment that it's the fallback (e.g. for re-running a partial publish that hit a transient API failure).

Depends on

• release/v11 exists.
• Three environments exist.
• NUGET_API_KEY migrated to env secret.

Notes

• Build.CI.GitHubActions.cs is the source of truth for consumer-facing generated workflows. This file (release.yml) is hand-written — header comment already documents this. The refactor doesn't affect generated output.
• This is the biggest single PR of the milestone. Worth landing the env + secret pieces first so this PR is purely YAML structure changes.

[ChrisonSimtian]

Scope add — tag protection for v* tags rolled into this issue (per discussion under #270).

The release.yml refactor and tag protection are paired concerns: both gate "who can actually fire a release." Doing them in one PR avoids a half-state where the workflow is tag-triggered but anyone with write access can push a v11.0.5 tag.

Additional acceptance criteria

• GitHub ruleset created targeting tags matching v* (or specifically v[0-9]+.[0-9]+.[0-9]+ if we want to also enforce semver shape).
• Ruleset rules: creation and deletion blocked except for bypass actors.
• Bypass actors: repo admins (currently just @ChrisonSimtian). Add maintainer role to bypass list when the contributor team grows.
• Ruleset enforcement: active (not evaluate).
• Branch deployment rule on the matching environments (Create three GitHub Environments: nuget-org, github-packages, github-releases #272) restricts to release/v* so a tag pushed to main can't fire a publish even if the tag escapes protection.
• Documented in docs/agents/release-and-versioning.md (alongside the existing "Branch protection on release/vN" section landed in docs(agents): release-branch model + branch-protection policy for release/vN #278).

Why a ruleset, not legacy tag protection

The legacy repos/.../tags/protection API endpoint is being deprecated. Rulesets are the modern replacement and support the same use case (creation/deletion rules with bypass actors) plus more flexible patterns. No reason to use the deprecated path for new setup.