Design signed project bundles and generation-coherent rollout after 1.0

## Decision already made

PR #355 and issue #312 intentionally stop at deterministic unsigned product inputs plus fail-closed Relay/Notary contract-hash checks. A new signed Registry Stack project root and remotely coordinated activation are deferred. They are not merge requirements for PR #355 and are not part of the 1.0 authoring contract.

This issue preserves the follow-up without implying that speculative infrastructure should be built now.

## Questions to answer from deployment evidence

- Is a signed project-root manifest needed beyond separately signed product inputs and ordinary deployment generation controls?
- What exact closure must it bind across Relay, Notary, scripts, fixtures, and public metadata?
- How should replicas attest identical generation identity and report drift?
- Does blue/green rollout need a Registry Stack protocol, or is a deployment reference using standard orchestrator primitives sufficient?
- Which rollback and break-glass events must be audited before mutation?

## Preconditions

Do not implement until at least one real multi-product deployment shows that deterministic generation, exact contract pinning, and normal orchestrator controls are insufficient.

## Acceptance criteria for a future design

- A concrete threat model names the failure the bundle prevents.
- The design does not create a second authoring model or configuration marketplace.
- Signatures bind the complete intended artifact closure and fail closed on omission or substitution.
- Replica identity and mixed-generation behavior are observable without exposing secrets or subject data.
- Rollout and rollback preserve audit-before-mutation and contract-hash invariants.
- Migration and compatibility rules are versioned before any wire or bundle format freezes.

## Related work

- #312
- #355
- registrystack/solmara-lab#8

Start by reviewing PR #355 and issues #312 and registrystack/solmara-lab#8, then gather evidence from a real multi-product deployment. Define the threat model, artifact closure, replica-generation observations, rollout and rollback audit events, and versioned compatibility rules; done means a concrete design meeting the listed acceptance criteria, not an implementation.

Written by the indexing model from the issue text.