Separate versions publishing privileges from release

[zsol]

Summary

This moves versions publishing back into a dedicated reusable workflow, keeping the release job limited to release creation and artifact publication instead of executing code from the external versions repository under the release token. The versions workflow remains isolated with empty top-level permissions and no persisted checkout credentials, preserving the intended least-privilege boundary.

[zsol]

Not sure we should do this tbh - it limits the scope of GITHUB_TOKEN so a compromised versions repository will not have access to it, which is technically a supply-chain escalation. But once someone has access to versions they can do much worse things than steal a GITHUB_TOKEN for this repo.

OTOH I don't have much context for why #1085 inlined these steps in the first place - what's the cost of an environment activation?

cc @woodruffw and @zanieb who will have more context

[zanieb]

Activating the release environment requires another manual approval.

We'd need to setup the release-gate workflow here to have the approval be automatic after the first manual approval.
We might need to do that anyway.

Regardless, we use a shared release environment across all of our projects. I'm not sure what this buys us if it doesn't use a dedicated separate environment? And I'm also not sure it's worth the effort of separating them all into least-permissions buckets, though it could be nice 🤷‍♀️ It would definitely require changes to the policy design in the release-gate service.