Publish the Registry Stack 1.0 support and responsibility contract

## Outcome

An adopter can determine, before installation, exactly what Registry Stack 1.0 supports, what is merely composable, what the institution must operate, and what is explicitly unsupported.

This is a release contract, not a marketing compatibility claim.

## Scope

Publish one versioned support and responsibility matrix covering:

- supported deployment profiles and their production, pilot, or development status;
- host and runtime CPU architecture;
- Registryctl, Relay, Notary, image, PostgreSQL, and configuration-format compatibility;
- single-product and combined-product topology limits;
- ingress, TLS, authentication, secret injection, key custody, database, storage, backup, audit, monitoring, and support ownership;
- restart, upgrade, rollback, recovery, and break-glass boundaries;
- public, private, admin, metrics, audit, and generated-artifact handling classes;
- author, reviewer, signer, activator, operator, source owner, evidence consumer, and decision-owner responsibilities;
- public support channels, security-reporting route, version window, and absence of an operational SLA unless separately contracted; and
- explicit unsupported claims, including topologies or providers for which release evidence does not exist.

Link the matrix from installation, project authoring, Compose operations, security hardening, lifecycle, release verification, and generated project documentation.

## Definition of Done

- [ ] Every support statement names an exact released artifact or profile and an evidence source.
- [ ] The matrix distinguishes supported, supported with institution-owned dependencies, architecturally composable but unsupported, and unsupported.
- [ ] A reference responsibility matrix assigns each lifecycle artifact and decision without assuming one institutional structure.
- [ ] Draft and released documentation cannot disagree about supported deployment profiles, architectures, databases, key providers, or lifecycle promises.
- [ ] Documentation tests fail when release metadata, generated help, compatibility data, or support statements drift.
- [ ] The final 1.0 candidate is audited against the matrix and every discrepancy is fixed or narrows the claim.
- [ ] An independent reader can use the matrix to answer whether a proposed environment is supported without maintainer interpretation.

## Non-goals

- Building an institutional IAM, ticketing, approval, monitoring, database, PKI, or backup platform.
- Claiming legal approval, interoperability certification, production authorization, or an operational SLA.
- Encoding country-specific agency names or governance hierarchies.

## Related work

- #198
- #203
- #358
- #496
- #497

Start by reviewing the related issues (#198, #203, #358, #496, and #497) alongside the installation, project authoring, Compose operations, security hardening, lifecycle, release verification, and generated project documentation areas named in the issue. Define the versioned support and responsibility matrix, then audit the 1.0 candidate and documentation tests or generated metadata for drift. Done means an independent reader can determine support, ownership, and unsupported boundaries without maintainer interpretation.

Written by the indexing model from the issue text.