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

Start with Registryctl's current image-lock and release-verification flow, then trace the supported Compose journey and the planned Kubernetes inputs. Use the required contract and Definition of Done as the acceptance checklist: mirrored digests must verify before startup, generated outputs must remain deterministic and secret-free, and the documented registry support matrix must match the exercised authentication shapes.

Written by the indexing model from the issue text.