Tighten release workflow harden-runner from audit to block mode

[chicks-net]

Summary

The release workflow added in #44 uses step-security/harden-runner with
egress-policy: audit (logging only), consistent with every other workflow
in this repo. The release job is the most supply-chain-sensitive one we have
(contents: write, id-token: write, attestations: write, plus a cosign
install and keyless signing), so it deserves egress-policy: block with an
explicit allowed-endpoints list.

Why not now

An allowed-endpoints list that's complete can only come from the egress
audit log of a real release run — the run touches GitHub APIs, the Sigstore
stack (Fulcio, Rekor, TUF), the Go module proxy, the setup-just release
download, and possibly more. Guessing the list before the first tagged release
risks breaking the release in public.

Acceptance criteria

• Cut the first tagged release with the current audit-mode workflow
  (see 🚀 [gha] add release workflow with signed binaries and SLSA provenance, fixes #42 #44 follow-up steps)
• Pull the egress audit log from that run's "Harden the runner" step
• Switch the release job to egress-policy: block with an
  allowed-endpoints list matching the observed calls (grouped by
  endpoint, with comments explaining each)
• Cut (or dry-run, if the list differs) another tagged release to confirm
  nothing breaks
• Optionally tighten the other repo workflows in a follow-up once the
  endpoint list patterns are established

References

• Review comment on 🚀 [gha] add release workflow with signed binaries and SLSA provenance, fixes #42 #44 that raised this:
  🚀 [gha] add release workflow with signed binaries and SLSA provenance, fixes #42 #44 (comment)
• step-security/harden-runner docs on block mode:
  https://github.com/step-security/harden-runner#egress-control