Support digest-preserving delivery through an institution-owned OCI registry

## Outcome

An adopter can mirror Registry Stack release images into an institution-owned OCI registry and deploy the mirrored images without weakening release identity, immutable pinning, provenance verification, or generated-project reproducibility.

This issue covers connected or pre-populated private registries. Fully disconnected installation is separate roadmap work.

## Current gap

Generated image locks accept literal public Registry Stack repositories. Production environments that prohibit direct pulls from public registries must currently choose between unsupported manual rewriting and retaining the public-registry dependency.

## Required contract

- Separate the immutable image identity from the deployment registry location.
- Preserve the exact upstream manifest or platform digest through mirroring.
- Bind any repository remapping to explicit, validated deployment input.
- Keep generated Compose and future Kubernetes inputs deterministic and secret-free.
- Support registry authentication without placing credentials in project YAML, generated reports, image locks, command output, or logs.
- Fail closed on tag-only references, digest mismatch, missing platform manifest, unapproved repository substitution, or incompatible release lock.
- Explain how release verification, SBOM, provenance, and image-signature evidence apply to the mirrored digest.
- Keep direct public-registry use as a supported simple default where policy permits it.

## Definition of Done

- [ ] Registryctl accepts a documented repository-mapping mechanism while retaining immutable digest verification.
- [ ] A clean test mirrors Relay and Notary images into an authenticated local registry and runs the supported Compose journey only from that registry.
- [ ] Generated files contain no registry credentials or secret-manager references that reveal private topology.
- [ ] Wrong digest, missing image, wrong architecture, tag mutation, and unapproved mapping fail before product startup.
- [ ] Repeated generation from identical project, release lock, and repository mapping is deterministic.
- [ ] Public documentation covers mirror, verify, deploy, rotate credentials, diagnose, and remove procedures.
- [ ] The release support matrix states which registry implementations and authentication shapes were actually exercised.

## Non-goals

- Operating an institutional registry.
- General tag-based deployment.
- A fully air-gapped installer or offline trust bootstrap.
- Re-signing images merely because their repository location changes.

## Related work

- #122
- #484
- #496
- #497

Inizia con il flusso corrente di image-lock e release-verification di Registryctl, quindi segui il percorso Compose supportato e gli input Kubernetes pianificati. Usa il contratto richiesto e la Definition of Done come checklist di accettazione: i digest con mirror devono essere verificati prima dell’avvio, gli output generati devono rimanere deterministici e privi di secret, e la matrice documentata di supporto dei registry deve corrispondere alle forme di autenticazione testate.

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