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.

Beginne mit den Wiederherstellungsverfahren aus #203 und den Relay- und Notary-Pfaden, die das replacement-bootstrap-Artefakt authentifizieren und verarbeiten müssen. Verfolge die erforderlichen Backup-Autoritäten und dauerhaft gespeicherten Artefakte und verwende anschließend die aufgeführten Ablehnungsfälle sowie die saubere Wiederherstellungsübung für einen einzelnen Knoten, um zu überprüfen, dass die vollständige Verifizierung vor der Zulassung von Datenverkehr abgeschlossen ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.