Runtime-owned approval surface for every approval, with the passkey bound to what is shown #178

Part of #173 (isolation plan). Depends on the design in #172.

Inbox approvals for capability grants, service, room and contact requests need only an Inbox launch token, which Home can mint (api/gateway_inbox.rs:204-236). Passkey step-up covers only wallet approve/send/delete, recovery-key export and import, full-recovery export and Inspector approve, and Home chooses the operation and request that the step-up covers (api/gateway_passkey_step_up.rs:203-224). Admin changes such as passkey promotion and guest registration need no step-up.

Design proposal: #172 note. Irzhy and Sasha acceptance gates implementation.

Done means

• Every approval kind (capability grants, service, room and contact requests, wallet, recovery import and export, admin changes, hosted egress, Runtime updates from UP-04: Add the System update flow #110) is shown by the Runtime-owned approval surface. Test: each approval kind, triggered from Home or an app, opens only on the host surface.
• The approval surface is a top-level Runtime-origin document with no Home frame in its ancestry; a test proves Home and app frames cannot script, read, cover or resize it.
• The host document renders the approval surface. Inbox is its name, and the Inbox capsule keeps the history. A test shows the approval is drawn by the host, not by the Inbox capsule.
• A cue that only the host can show appears at sign-in and on every approval. It is a phrase the user chose at sign-in, never sent to the Home GUI or apps, so look-alike dialogs drawn by Home or an app are recognisable. A test proves the phrase never reaches a Home or app frame.
• Recovery Kit import on a new machine, where no passkey exists yet, follows a defined host-only flow that registers a new passkey before any secret is entered. An end-to-end test runs this flow on a fresh profile.
• The host renders one immutable request. The WebAuthn challenge is derived from the request's digest, nonce, expiry and operation. Verification is one-shot. A request expires at its stated expiry, and cancelling it ends it with no grant. Test: a changed amount or target after the prompt, a replayed assertion and an expired request are all refused.
• Denials and expiries are visible in Inbox and leave no partial grant. Test: a denied and an expired request each show in Inbox history, and the capability is not usable.
• Sasha accepts the approval screens; Irzhy reviews the binding. Proof: their sign-off is linked in this issue.
• The shared Hacked-Home regression suite in CI #180 suite enumerates every gateway/Runtime route and capability at test time; this issue supplies operation-specific attacks from hacked Home, hacked app frames and a foreign origin, with a permitted control for each allowed scope.

Browser plan reconciliation — 2026-10-08

#87 retains Wallet/chain and actual transaction acceptance. #290/#291 consume the same Runtime-owned trusted approval for delegated operator and remote/Wallet effects: exact principal/page/action binding, explicit handoff/takeback and replay/refusal tests. Ordinary website/app content projects a request; the trusted surface owns approval. Human review and existing design gates remain here.