Clarify registryctl's 1.0 adopter contract

[jeremi]

What changed

• Preserve the current v0.12.2 project starters while making the evidence-versus-programme-decision boundary explicit across DHIS2, snapshot, and custom integration journeys.
• Remove the hidden init relay and init spreadsheet-api aliases so the supported project-authoring workflow is the single canonical setup path.
• Define a strict, versioned registryctl smoke report and deterministic exit-status contract with matching schema, tests, reference documentation, and integration fixtures.

Why

The pre-1.0 surface mixed evidence production with downstream programme decisions and retained setup aliases outside the documented workflow. That made the product harder to learn and left automation without a stable smoke contract.

Implementer impact

Implementers get one supported authoring path, clearer responsibility boundaries, and a machine-readable smoke result suitable for CI without scraping prose.

Validation

• cargo fmt --check
• cargo test --locked -p registryctl (262 passed)
• python3 -m unittest release/scripts/test_integration_e2_runner.py (37 passed)
• npm test (117 passed)
• npm run check:content
• npm run check:markdown (0 errors)
• prohibited-pattern scan and git diff --check

Review note

This touches Tier-C security/privacy documentation. Maintainer source-pack sign-off is required before merge.

Closes #417.
Closes #238.

[jeremi]

Superseded by #469, the single ready integration PR for this reviewed 1.0 batch. This PR's exact head is preserved as an ancestor of #469, so its implementation and commit history are retained; only the merge path has been consolidated.