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.

Scritto dal modello di indicizzazione a partire dal testo della issue.