Beta gate: reduce/clarify Door A (F2) custody exposure

[Jolah1]

The easy-setup (F2 / Door A) path lets the server reconstruct the heir's key from (master_key, heir_email, vault_id). It's documented and inherent to that path, not a bug, but it's the weakest custody story and should be minimized for beta. (Door B / password-vault is genuine self-custody.)

Step by step

1. Make Door B the clear default in setup; present F2 as an explicit "my heir has no wallet and I accept the tradeoff" choice with plain-language disclosure.
2. Land the KMS work (Beta gate: move GHOSTKEY_MASTER_KEY to a KMS/HSM (envelope encryption) #184) first: it shrinks the F2 risk from "env var leak" to "KMS compromise."
3. Envelope-encrypt the at-rest claim token under the per-vault KMS data key so a DB leak alone never yields the F2 heir key.
4. Offer an F2 opt-out / upgrade path: let an owner re-vault an F2 heir into a Door B vault once the heir has a wallet (ties into issue Master key rotation: design + runbook #27).
5. Re-state the tradeoff wherever F2 is chosen, in the app and the recovery kit, so no one is surprised. (Copy already corrected in fix(copy): make heir-key custody claims accurate (design review C0) #156; keep it accurate.)

Done when

Door B is the default, F2 is opt-in with clear disclosure, the at-rest token is KMS-wrapped, and there's a path off F2.

[Jolah1]

Shipped the clarify half in #191: corrected the Door A custody overclaims (setup portal copy + header/inline comments + Privacy Policy) — verified in current code that the master key can reconstruct the Door A heir key (at-rest token sealed under master key, opened routinely by the scheduler to send the link).

The reduce half is already in place: the at-rest claim token is sealed under the per-vault master-key AEAD, so it benefits directly from the KMS sourcing in #184 (set GHOSTKEY_MASTER_KEY_CMD to put the master key in a KMS).

Decision: kept Door A as the default (not flipped to Door B as originally proposed) — the product's heirs are non-technical and usually have no wallet/xpub, so forcing Door B would break the core use case. Door B stays the discoverable, fully non-custodial option.

Remaining (optional): an in-app F2→Door B 'upgrade once your heir has a wallet' path (ties into #27).

[Jolah1]

Status check against the "done when" criteria, since only part of this is actually done:

• Clear disclosure wherever F2 is chosen — corrected in fix(copy): make heir-key custody claims accurate (design review C0) #156 and fix(copy): make Door A custody disclosure accurate [#186] #191 (PasswordSetupPortal.tsx, Legal.tsx). Copy honestly states the server can reconstruct the Door A heir key; never claims impossibility.
• Door B is the default — deliberately NOT done. Door A stays default because the target heirs are non-technical and have no wallet. This is a conscious deviation from the issue.
• At-rest claim token KMS-wrapped — not done, and now moot: Beta gate: move GHOSTKEY_MASTER_KEY to a KMS/HSM (envelope encryption) #184 was resolved by accepting Fly secrets rather than a per-vault KMS data key, so there's no KMS key to wrap the token under.
• Path off F2 (re-vault into Door B) — not built.

Proposed rescope for beta: since Door A is intentionally the default and there's no KMS, this issue should narrow to "the residual work that still makes sense":

1. An F2 -> Door B upgrade/off-ramp once an heir gets a wallet (ties into Master key rotation: design + runbook #27).
2. Optionally, encrypt the at-rest claim token under a second Fly secret (a poor-man's envelope) so a DB leak alone doesn't yield the F2 heir key.

Leaving open pending a decision on that rescope.

[Jolah1]

Closing. The disclosure copy is done (#156/#191), and the remaining 'done when' items no longer apply: Door A stays the default by design (non-technical heirs have no wallet), and the at-rest-token KMS-wrapping depended on the dedicated KMS we deliberately skipped (#184 resolved on Fly secrets). The one idea still worth doing — an F2 -> Door B upgrade path — is better tracked on its own if/when it's prioritized, not as a beta gate.