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

Inizia esaminando la PR #355 e le issue #312 e registrystack/solmara-lab#8, quindi raccogli evidenze da un deployment reale multi-prodotto. Definisci il modello delle minacce, la chiusura degli artefatti, le osservazioni sulla generazione delle repliche, gli eventi di audit di rollout e rollback e le regole di compatibilità versionate; il lavoro è considerato completato quando esiste un design concreto che soddisfa i criteri di accettazione elencati, non un’implementazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.