Support authenticated replacement-instance bootstrap

## Outcome

An operator can restore or replace a single-node Registry Stack instance from approved backup history without weakening anti-rollback protection, reusing an old instance identity incorrectly, or requiring an ad hoc signing ceremony during an outage.

This complements #203 and does not expand the 1.0 adopter-runtime PR. High-availability and multi-replica recovery remain in #507.

## Design checkpoint

Define the smallest authenticated proof that lets a fresh instance establish:

- the intended product lane and replacement instance identity;
- the accepted trust anchor and authenticated anchor history;
- the latest approved bundle sequence and hash;
- the matching database, audit, and correctness-state snapshot;
- the operator authorization for replacement rather than rollback or cloning.

## Security invariants

- A stale, partial, cross-lane, or cross-instance backup cannot become current.
- Replacement cannot use AcceptUnsigned, AcceptRollback, or another silent break-glass path.
- Trust anchors are pinned independently of the closure they authorize.
- Audit evidence records the old identity, new identity, approved history, and recovery decision without secret values.
- Product-owned exact verification completes before traffic admission.

## Definition of Done

- [ ] A versioned replacement-bootstrap artifact and ownership model are documented.
- [ ] Relay and Notary authenticate and consume it through closed product-owned actions.
- [ ] Backup inventory and #203 recovery procedures include every required authority and durable artifact.
- [ ] Tests cover valid replacement plus stale sequence, wrong lane, wrong instance, anchor swap, partial snapshot, replay, and mixed-generation rejection.
- [ ] A clean single-node restore exercise reaches exact verification before traffic.

## Non-goals

- Automatic disaster-recovery orchestration.
- Multi-replica fencing or failover.
- Bypassing normal signed approval and anchor-rotation procedures.

Inizia con le procedure di ripristino di #203 e i percorsi Relay e Notary che devono autenticare e consumare l’artefatto replacement-bootstrap. Traccia le autorità di backup necessarie e gli artefatti durevoli, quindi usa i casi di rifiuto elencati e l’esercitazione di ripristino pulito di un singolo nodo per verificare che la verifica esatta sia completata prima dell’ammissione del traffico.

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