User keys and private data that the host cannot read #209

Part of #173 (isolation plan).

Anders decided on 2 October that user keys and private data must be protected from the host, including the operator of a hosted Home such as the public seed. There are no real users or value on hosted accounts yet, but that will change; this must be done before hosted accounts hold real value. Until then hosted accounts stay non-private demo accounts without wallets (#174).

Facts

• Keys are plain owner-only files in the Runtime data folder today; the passkey only authenticates sign-in (details in Self-hosted Home: keys in the OS keystore, unlocked by the user's passkey #210).
• Signed releases and capsules are the base, but signatures only help when something the operator does not control verifies them. On a hosted Home nothing on the user's side does this today: the browser runs whatever page the operator serves, and root on the host can run a different binary or read memory.

Done means

• A design note, reviewed by Irzhy, chooses the hosted trust model: client verification of signed code (Hosted Home: the user's own client verifies the signed code before it handles keys #211), a confidential VM checked by attestation (Hosted Home: run in a confidential VM that the user's client verifies by attestation #212), or both, with cost, platform limits and the order of work.
• Self-hosted Home: keys in the OS keystore, unlocked by the user's passkey #210 (self-hosted keys in the OS keystore, unlocked by passkey) is done.
• The chosen hosted issues are done. Test: with the full data folder, root access and control of the served pages, the operator cannot read a hosted user's wallet key or private data.