Extend release.yml beyond staging: winstaging, aarch64staging, gpu

#2276 added `release.yml`, which covers `staging-deploy`, `staging-shutdown` and `staging-cleanup` so those can be driven without sitting at the admin node. Staging is only one of the environments a full release touches, so this is a note of what generalising the rest would involve, written down before the context is lost.

The environments still to cover:

**winstaging / winprod.** These need an extra step before any deploy: a Windows package has to be built, and that workflow lives in the compiler-explorer repo rather than here. It is `CE Windows Build` (`.github/workflows/deploy-win.yml`), a `workflow_dispatch` whose `buildnumber` input is the `gh-` git tag, so the tag has to exist already. Any generalisation needs to either sequence that cross-repo step or assume it has been done. Windows also has its own compiler set, so smoke tests baseline against `winprod`, not `prod`.

**aarch64staging / aarch64prod.** Execution-only. The path router exposes no compiler dropdown, so `/api/compilers` is empty by design and a compiler-count check is meaningless. The useful test is indirect: compile an AArch64 binary on the paired compilation environment and run it, which offloads execution to the aarch64 node.

**gpu.** Not a staging/prod pair, so `shutdown` and `cleanup` do not apply in the same way, and it is a production environment rather than a rehearsal one. It also has ordering significance: if a release adds GPU compilers, gpu has to be deployed before discovery runs on the main node. GPU instance types are capacity-constrained on AWS, so a deploy can legitimately sit waiting for capacity rather than failing.

Design questions worth settling before extending the command list rather than after:

- The current `case` maps a command to an environment and an action, which stays readable at three entries but would be twelve or more once every environment is covered. Two inputs (environment plus action) would be tidier but reintroduce the free-form-environment risk that the case deliberately removes. A constrained choice for each is probably the answer.
- Prod operations should almost certainly carry an actor allowlist even though staging does not.
- Environments differ in which subcommands are meaningful, so an environment/action matrix has invalid combinations that need rejecting rather than silently doing something odd.

Not urgent, and each environment is updated infrequently. Filing so the shape of the problem is recorded rather than rediscovered.

Start by reading the current release.yml case and the compiler-explorer workflow at .github/workflows/deploy-win.yml, then trace how each environment and action is represented. Done means a settled constrained environment/action design, valid-combination checks, production actor restrictions, and coverage for the Windows, AArch64, and GPU release paths.

Written by the indexing model from the issue text.