Run a compiler-generated combined Relay and Notary project live

[jeremi]

Context

Registry Stack PR #355 proves combined Registry Relay and Registry Notary project generation through compiler, fixture, and in-process integration tests. The legacy monorepo lab is intentionally frozen because Solmara Lab will replace it, so the live two-process topology belongs here.

This issue must prove the deployed path without making product or version metadata select behavior.

Scope

• Author or import one concise Registry Stack combined project.
• Generate Relay and Notary product inputs through registryctl.
• Boot both services from those generated inputs.
• Exercise the authenticated, compiler-pinned Notary-to-Relay consultation path over the network.
• Demonstrate one coordinated generation change and fail-closed mixed-generation rejection.
• Keep source capabilities product-neutral. Changing or removing source product/version metadata must not change http, script, or snapshot capability selection.
• Use synthetic fixtures and environment-only secrets.

Acceptance criteria

• One documented command or short command sequence generates and starts the combined topology from a clean checkout.
• A successful claim evaluation proves the live Notary-to-Relay path.
• A mismatched contract generation fails closed before source work.
• Generated inputs, runtime logs, and retained evidence contain no credentials or raw subject values.
• CI validates the project and parses the generated product configs even if the full live topology remains a scheduled gate.
• The legacy monorepo lab is not modified.

Related work

• Converge Relay and Notary on Registry Stack project authoring registry-stack#355
• refactor: derive Relay, Notary, and manifest artifacts from one Registry project model registry-stack#312

[jeremi]

Current acceptance status after #9 and #10

PRs #9 and #10 completed most of this issue:

• six authority-owned combined Relay and Notary projects exist;
• compiler-generated inputs are reproducible for local and hosted environments;
• the authenticated Notary-to-Relay claim path, PostgreSQL ownership topology, restart persistence, candidate pin validation, and product-neutral source-capability boundary are covered;
• project checks, offline fixture tests, and deterministic runtime-closure comparison pass with the checksum-verified pinned registryctl;
• the legacy monorepo lab remains untouched.

Three acceptance gaps remain, so this issue should stay open:

1. Normal CI mocks the registryctl command sequence instead of running the real explicitly pinned binary. The Quick Start generates fixtures and secrets, then starts committed closures; it does not provide one clean-checkout command that regenerates the Registry Stack closure before startup.
2. Solmara has not yet proven a coordinated successor generation where an intentionally mixed Relay/Notary pairing fails before any Relay execute request or source work, followed by successful activation of the complete successor pair.
3. Generated runtime closures, captured service logs, and retained proof output are not yet scanned together for generated credentials and known synthetic subject identifiers.

The remaining packet is implementation-ready without a new product decision: wire real pinned project check/test/runtime comparison into normal CI, document a clean-checkout generate-and-start target, add one isolated SRO blue/green mixed-generation proof in the release-candidate gate, and add value-safe leak scanning that reports locations but never matched values.

[jeremi]

Implementation merged in #11

PR #11 is merged as 0e17b77 with green required CI and a clean independent re-review.

The previously open implementation gaps are now covered:

• normal CI uses the real checksum-verified registryctl version pinned by versions.env for all six authority project checks, offline tests, and deterministic runtime-closure comparison;
• just up-generated is the documented clean-checkout generate, verify, and start journey;
• the release-candidate workflow includes the isolated SRO blue/mixed/successor proof;
• the mixed successor Notary must fail on the exact Relay contract-pin mismatch while Relay completion-intent and dispatched-permit counts remain unchanged;
• the complete successor pair must execute a fresh successful minimized claim;
• generated closures and captured proof output are scanned for exercised subjects and environment credentials with bounded, redacted failure diagnostics;
• cleanup failures cannot hide the primary contract-generation failure.

This issue remains open for one sequential release gate: run the merged release-candidate workflow against the exact Registry Stack candidate tag and matching Relay/Notary digests selected for 1.0, then link the successful workflow evidence here. Source-branch or mismatched-image evidence does not satisfy that final gate.