Complete one independent deployment pilot before Registry Stack 1.0

## Context

Automated tests and maintainer-run demonstrations do not prove that an external operator can configure and run the frozen product. Before 1.0, at least one named integration should reach the externally piloted evidence level: an operator outside the Registry Stack implementation team configures and runs the post-convergence release candidate and the resulting findings are triaged.

This is an adoption and operability gate, not a request to expose a country's private deployment or data.

## Scope

- Select one maintained, pinned integration profile and an external operator or partner able to run it independently.
- Use a post-convergence 1.0 release candidate and only the documentation and release artifacts intended for adopters.
- Have the external operator install or deploy the supported topology, author or adapt the Registry project, configure environment bindings, run offline checks, and execute the documented end-to-end journey.
- Exercise Relay consultation and, where the selected journey includes Notary, the consultation-backed claim or credential flow.
- Record usability, configuration, diagnostics, upgrade, operational, security-boundary, and documentation findings.
- Triage every finding as fixed before 1.0, an explicitly accepted limitation, or evidence that the support claim must be narrowed.

## Acceptance criteria

- An external operator completes the frozen profile without implementation-team members silently editing generated artifacts or taking over the deployment.
- The exact release candidate, integration version and operation, supported topology, and journey are recorded.
- The operator can diagnose ordinary configuration and source failures using shipped commands and documentation.
- No credentials, personal data, private endpoints, or confidential deployment details appear in GitHub evidence.
- Blocking findings are resolved and verified; accepted limitations are reflected in the public support wording and operator guidance.
- A concise public, redacted pilot report links the resulting issues and states exactly what the pilot did and did not prove.

## Non-goals

- Product-official endorsement by the upstream OpenCRVS, DHIS2, or OpenSPP project.
- Publishing country data or deployment secrets.
- Claiming broad production readiness from one pilot.

Start by identifying a maintained, pinned integration profile, an external operator, and the post-convergence 1.0 release candidate to pilot. Follow the documented deployment, offline checks, and end-to-end journey, then record and triage findings. Done means blocking findings are verified as resolved, accepted limitations are reflected publicly, and a concise redacted pilot report links the resulting issues.

Written by the indexing model from the issue text.