Deliver a verifiable disconnected installation and upgrade workflow

## Outcome

Registry Stack can be installed, verified, upgraded, rolled back, and recovered in an environment with no network access to public source, release, transparency-log, package, or container-registry services.

Roadmap default: 1.2. Reprioritize only when a release-scoped deployment requirement mandates disconnected operation.

## Required distribution unit

Produce a versioned disconnected release set containing or closing over:

- Registryctl and required platform binaries for supported host architectures;
- exact Relay and Notary OCI images for supported runtime architectures;
- release lock, checksums, signatures, certificates or trust material, SBOMs, provenance, vulnerability evidence, schemas, and notices;
- the supported Compose deployment inputs and any required migration tooling;
- an authenticated manifest that inventories every file, image, digest, size, sensitivity, and intended consumer; and
- an explicit statement of what is not included, such as external databases, identity providers, secret stores, HSM modules, ingress, monitoring, or country integration data.

## Workflow

Document and automate:

1. Assemble and verify the release set in a connected preparation environment.
2. Transfer it through an institution-approved medium.
3. Verify trust and complete closure without network access.
4. Import images into an institution-owned registry or local OCI runtime.
5. Apply an explicit digest-preserving repository mapping.
6. Install and run the supported topology.
7. Perform a disconnected upgrade, rollback decision, and recovery exercise.
8. Export bounded verification evidence without private values.

## Security requirements

- Offline verification must not silently skip a transparency, certificate, provenance, or signature check that was required online.
- Trust bootstrap and trust rotation must be explicit and independently reviewable.
- Repository remapping must preserve exact image identity.
- The release set must contain no credentials, private keys, project secrets, source data, or environment-specific endpoints.
- Missing, extra, replaced, downgraded, expired, or wrong-architecture artifacts fail closed before activation.

## Definition of Done

- [ ] CI builds the complete release set from one immutable candidate and validates its authenticated closure.
- [ ] An isolated no-network test machine verifies, imports, installs, starts, exercises, stops, upgrades, and recovers the supported topology without undeclared downloads.
- [ ] Negative tests cover omission, substitution, downgrade, stale trust, wrong architecture, altered image mapping, and partial transfer.
- [ ] The procedure supports at least one authenticated private registry and a registry-free local import path where the supported deployment permits it.
- [ ] Documentation distinguishes disconnected installation from offline fixture validation and from runtime source connectivity.
- [ ] Release evidence records exact inputs, outputs, digests, verification steps, and limitations.
- [ ] The support matrix states which disconnected topology, transfer model, trust model, and upgrade hops are supported.

## Non-goals

- Operating an institutional artifact repository or transfer process.
- Bundling external infrastructure products.
- Automatic access to a deployment environment.
- Treating a local registry alone as complete disconnected-install support.

## Related work

- #122
- #484
- #499

Start by reviewing related issues #122, #484, and #499, then locate the existing CI, supported Compose deployment inputs, release tooling, and support matrix. Run the isolated no-network workflow against one immutable candidate and its release set. Done means installation, verification, upgrade, rollback, recovery, and the listed negative tests complete without undeclared downloads, with bounded evidence recorded.

Written by the indexing model from the issue text.