Publish native ARM64 runtime images with cross-architecture parity

## Outcome

Registry Relay and Registry Notary are published and supported as native Linux ARM64 images with the same security, correctness, release, and lifecycle contracts as the supported Linux AMD64 images.

Roadmap default: 1.2. Reprioritize only when a release-scoped deployment requirement mandates ARM64 runtime nodes.

## Scope

- Publish a multi-platform OCI index or an equivalently explicit per-platform release contract.
- Extend the release lock and verification workflow to bind the intended architecture-specific manifest digest.
- Build, test, scan, attest, sign, and publish both architectures from the same immutable source candidate.
- Exercise the supported Compose profile natively on ARM64.
- Prove generated artifacts, configuration, API behavior, state formats, database behavior, audit behavior, and wire contracts remain architecture-independent.
- Document provider-specific native-library limits, especially external PKCS#11 modules.

## Definition of Done

- [ ] Release workflows publish native Linux AMD64 and ARM64 Relay and Notary manifests under an authenticated multi-platform index or documented equivalent.
- [ ] Registryctl selects only a release-supported architecture and fails before mutation on an unavailable or mismatched platform.
- [ ] Native ARM64 CI or release evidence runs the supported Relay, Notary, combined Compose, PostgreSQL, configuration-bundle, audit, restart, and recovery journeys.
- [ ] SBOM, vulnerability, provenance, repeatability, and signature evidence is bound to each platform manifest and the index.
- [ ] Cross-architecture tests prove canonical generated artifacts, protocol output, persisted state, and signed evidence remain compatible where promised.
- [ ] Performance and sizing documentation distinguishes architecture-specific measurements.
- [ ] PKCS#11 documentation states that vendor modules remain external and require native ARM64 validation before support can be claimed.
- [ ] Installation and support documentation no longer recommends AMD64 emulation for a supported ARM64 host.

## Non-goals

- Supporting every CPU architecture.
- Certifying third-party native libraries or HSM modules.
- Claiming identical performance across architectures.
- Supporting ARM64 solely because Registryctl itself has an ARM64 binary.

## Related work

- #122
- #380
- #496
- #497
- #501

The issue names release workflows, Registryctl, the supported Compose profile, PostgreSQL journeys, and ARM64 CI or release evidence rather than specific files. Start by locating those entry points and mapping the current AMD64 release, verification, signing, and platform-selection flow. Done means the listed ARM64 release, compatibility, evidence, documentation, and provider-limit criteria are all satisfied.

Written by the indexing model from the issue text.