Create three GitHub Environments: nuget-org, github-packages, github-releases

[ChrisonSimtian]

Sibling of milestone #13. RFC #267.

What

Create the three GitHub Environments that the multi-channel release workflow will deploy to. Channel-keyed (not major-keyed) — the per-major granularity is captured in the deployment ref.

Environment	Target	Approval gate?
nuget-org	https://api.nuget.org/v3/index.json	Yes — irreversible publish, restrict to maintainers
github-packages	https://nuget.pkg.github.com/ChrisonSimtian/index.json	No
github-releases	GitHub Release on this repo with nupkgs attached	No

Acceptance criteria

• Three environments exist in repo Settings → Environments.
• nuget-org has required reviewers configured (maintainer list — coordinate with Chris).
• Branch deployment rule on all three: only release/v* (and maybe main while we still cut releases off main during transition).
• Documented in docs/agents/release-and-versioning.md once the docs PR lands.

Notes

• NUGET_API_KEY secret migration is a separate sibling issue — this issue is just the environment shells + approval rules.
• The workflow refactor (turning tag pushes into 3 deployments) is also separate.

Depends on

• Nothing — this is independent infra work that can happen in parallel with the branch cut.

Blocks

• NUGET_API_KEY migration.
• Refactor release.yml to tag-triggered + multi-channel.

[ChrisonSimtian]

Done. Three GitHub Environments created via API.

What landed

Environment	Required reviewers	Branch policy	Purpose
nuget-org	@ChrisonSimtian	release/v*, main	nuget.org publish (gated)
github-packages	—	release/v*, main	GitHub Packages NuGet feed + Nuke.* shim push
github-releases	—	release/v*, main	GitHub Release with nupkg artifacts attached

Decisions

• Approver on nuget-org: just Chris for now (sole repo admin). Easy to add Dennis or others later via gh api -X PUT repos/.../environments/nuget-org with an expanded reviewers array — left as a future tweak when the contributor team grows or trust thresholds need adjusting.
• main in branch policy alongside release/v*: kept for the transition. Until Refactor release.yml: tag-triggered, multi-channel via environments #274 lands and the trigger flips to push: tags: v* on release/v*, manual workflow_dispatch runs from main need to be able to target these environments. Once Refactor release.yml: tag-triggered, multi-channel via environments #274 ships, the main policy entries should be dropped — added to that issue's acceptance criteria implicitly via the tag-trigger requirement.
• Custom branch policies (not protected_branches: true): explicit allow-list is safer than "any protected branch". Even if a feature branch gets branch-protected one day, it won't accidentally become deployable.

What this issue did NOT touch

• NUGET_API_KEY secret migration — tracked separately in #273. Now unblocked.
• release.yml workflow refactor — tracked in #274. Still gated on Move NUGET_API_KEY from repo secret to nuget-org environment secret #273.
• Documentation in docs/agents/release-and-versioning.md — deferred to umbrella docs PR #276, per the pattern (one consolidated v11-restructure docs entry rather than fragmenting across sub-PRs).

What's unblocked

• Move NUGET_API_KEY from repo secret to nuget-org environment secret #273 — move NUGET_API_KEY from repo secret to nuget-org environment secret.