Define and test the lifecycle contract: what survives eviction, restart, and upgrade

[NotASithLord]

The second of the two items the post-merge #298 review would require before an unqualified 1.0. Unlike #305 this is not an architecture change — it is making the observable semantics explicit and tested.

Why

peerd's security architecture is ahead of its operational maturity. A 1.0 is a compatibility and recovery promise as much as a security one, and right now the answers to "what happens when the worker dies mid-run" live in people's heads and in scattered code, not in a contract anyone can check.

MV3 makes this sharper than usual: service-worker eviction is routine, not exceptional.

What to document and test

Interruption

• What survives service-worker eviction? (vault mirror semantics are now pinned by feat(credentials): "use but can't see" — DPoP proof-of-possession + a non-extractable vault key #298 — the rest is not)
• What survives a browser restart?
• What happens to in-flight actors, engine instances, and open sandbox tabs?
• Can an operation have completed after an interruption the user saw as a failure? This is the one that matters most — a tool call that wrote something and then lost its result is indistinguishable from one that never ran, and the agent may retry it.
• What is the retry/idempotency posture for each tool that has side effects?

Migration

• Vault blob format (there is already vault/blob-migration.js — is the contract written down?)
• Sessions, skills, memory, OPFS contents, engine registries, DPoP key records
• Supported upgrade paths, and what a downgrade does (currently: unknown)
• Data export / recovery behavior

Definition of done

• A docs/ page stating the contract per surface — not prose describing the code, but the promises, in the form a user or auditor can hold peerd to.
• Fault-injection coverage for the interruption cases. The CDP e2e harness (scripts/cdp/run-e2e-verify.mjs) already drives a real extension end to end and is the natural place to kill the worker mid-turn and assert what comes back.
• Migration tests that load an old profile shape and assert it upgrades, rather than only testing the current shape round-trips.

A fully durable operation registry (roadmap P1) would be the ideal answer, but it should not gate this: the semantics need to be stated and true before they need to be ideal.