Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422

Problem

Every identity in a stack is a DID, and the owner's is usually a did:key. A did:key is its key:

• Losing the key loses the identity. The local stack keeps working, but no one can authenticate as its owner to a server again. The README's key-custody recipes say where to keep the key; nothing helps a person recover it.
• A leaked key can't be replaced. identity.md § Deferred: key rotation defers rotation.
• Who acts as a Group is unanswered. identity.md § Group gives a group "its own keypair (held by its admins)" and leaves open who may act as the Group: accept grants, own its stack, speak to other stacks. In practice, whoever holds the key is sovereign over the group's own rules.

Leaving custody entirely to each app is a footgun for individuals and an unexamined default for groups. Building one answer into core would be too prescriptive for people who know what they're doing.

Directions

• A rotatable identity comes first. Recovery without rotation is half a fix. Options: a rotatable DID method (did:plc, did:webvh, KERI), or a successor-key record in the stack signed by the old key or by a recovery quorum. Design: proving who publishes an app (signed manifests, publisher pinning, certified keys) #404 asks whether app-publisher proof should be designed with key rotation; this is the same problem.
• Delegation over shared group keys. The Group's identity authorizes each admin's own DID (capability tokens such as UCAN). No secret is shared, and removing an admin revokes one delegation instead of re-keying. The server would need to accept an admin acting under a delegation from the owner DID; today it authenticates exactly one owner DID.
• A wrapper package with replaceable defaults. Keychain storage, a recovery kit (a printed code, optional social-recovery shares held by trusted people), group setup and export, each plugged into a seam core already has (the credential signing callback). Replacing one piece needs no "eject".
• Formats live in the spec, not the wrapper. Recovery shares, delegation tokens and the export format are specified, so the material stays usable if the wrapper disappears.

Questions

• Which rotatable identity: an external DID method, or a stack-hosted successor record?
• What does a recovery quorum sign, and where does the record live when the stack itself is what's being recovered?
• Does delegation replace the group keypair, or sit on top of one?
• Is passkey-backed storage acceptable as a default, given it ties recovery to a platform vendor?

Unblocks

#423 (a stack names its own roster), #428 (sealed Records) and #429 (group charters).