Keeper registry persistence: created instances survive a reload — serialize/rehydrate through the accept path

Context

T4.1 of the harness pillar (#13349) — the persistence line every registry decision reserved for: blueprintSnapshot is registry-owned + structured-clone-safe, records are history-complete (disposed kept), and the accept path is the ONE re-entry door. A page reload currently loses every created widget; the wedge's product promise ("a stranger types an intent and gets a live app") needs the app to still be there.

The Fix

• Serialize: the registry's live+disposed records (the snapshot IS the serialization source — the field was designed for this) to a durable store. v1 target: the session-scoped persistence the framework's app-worker offers; the durable-git/T4-full story stays out (this is reload-survival, not history).
• Rehydrate on create-module boot: for each persisted LIVE record, replay acceptBlueprint(record.blueprintSnapshot, record.instanceId) through the UNCHANGED accept path — same validator, same stage seam, same insert-registrar (idempotent: the duplicate-id pre-check refuses if a record already re-registered). Disposed records restore as registry history WITHOUT instantiation.
• The provider's flow state rehydrates from the outcome (any live instances → materialized), keeping the SSOT's boot-truth rule: render state derives from what EXISTS, never from a persisted flow flag (a persisted snapshot-of-flow-state would be the exact snapshot-as-self class the identity work just banned — state re-derives from the trail of records).

Acceptance Criteria

• Round-trip unit: register 2 + dispose 1 → serialize → clear → rehydrate → 1 live instance re-accepted through the real path, 1 disposed record restored as history, resolution semantics identical pre/post.
• Rehydration validates EVERY snapshot through validateBlueprint again (a tampered/stale persisted payload refuses bounded — persistence is an input, inputs are never trusted).
• Flow state derives from rehydration outcome, never persisted directly.
• Idempotent double-rehydrate (the duplicate-id refusal proves it).

Out of Scope

Durable/git-backed persistence + cross-session history (the full T4 line, its own leaf when the product needs it) · persisting external (non-keeper) instances · migration of persisted payloads across schema versions (registry versioning carries it: grid@1 refuses under a future grid@2-only registry — correct and loud).

Related

Parent #13349 (T4.1) · the registry (merged — snapshot ownership + history-complete were built FOR this) · the accept path (merged — the ONE re-entry door) · the SSOT's boot rule · the snapshot-as-self ban (recorded, identity epic).

Claimable — non-Fable implementable; every contract it consumes is merged and unit-pinned.

Origin Session ID: b9b95ac6-42f5-47a3-b58f-6071f79657e8 Retrieval Hint: "keeper registry persistence reload survive serialize rehydrate accept path replay idempotent"