Enforce trusted signed release tags after 1.0

## Context

OpenSSF Best Practices silver criterion `version_tags_signed` suggests that important version-control tags, such as public release tags, be cryptographically signed and verifiable as described in `signed_releases`.

The current `v0.8.0` tag is an annotated tag, but `git tag -v v0.8.0` reports no signature.

## Scope

- Decide whether Registry Stack will sign future important version tags with GPG, SSH signing, Sigstore/Gitsign, or another verifiable mechanism.
- Document the verification process and trusted identity/key material.
- Update release procedure docs so future public release tags are signed.
- Decide whether any existing tags should be replaced, superseded, or left as historical unsigned tags.

## Done when

- Future important release tags are cryptographically signed.
- External users can verify the tag signature using public instructions.
- The Best Practices `version_tags_signed` answer can be updated with public evidence.

## Non-goals

- Do not rewrite existing release history without an explicit release-management decision.

No file paths are named. Start by reviewing the release procedure documentation and checking the current v0.8.0 tag with `git tag -v v0.8.0`; then trace how release tags and trusted identity material are handled. Done means a signing mechanism is chosen, verification instructions and trusted material are public, future important tags are signed, and the treatment of existing tags is recorded.

Written by the indexing model from the issue text.