feat(agent): port high-risk partitions and approval gates

High-risk partitions move ssh/pgp/seed/nostr/managed_account records out of
the vault index into a separately encrypted file, so those kinds need a SECOND
factor beyond the master password. The index keeps a stub carrying kind, label
and archived — enough to list, nothing more.

Both file formats are byte-compatible with Python and verified bidirectionally:
TS unwraps a Python-written key envelope and reads a Python-written partition,
and Python unwraps a TS-written envelope and reads a TS-written partition. That
matters more than usual here — the entries are SSH keys, PGP keys and seeds, so
a partition only one implementation can open is lost secrets, not an
inconvenience. This required a Fernet encryptor in core, which had been
decrypt-only by design; the header now says why that exception exists and that
no other Fernet payload should ever be written.

**One deliberate divergence, and it is the reason this is not a straight port.**
Python records an unlock session in agent_high_risk_unlock.json, and that record
contains the partition_key_tag — the value the partition file's encryption key
is derived from. So for the life of any Python unlock session the partition is
decryptable from disk alone, with no factor, by anything that can read the app
directory; both files live in the same directory, so "can read one" implies "can
read the other". That voids the guarantee the partition exists to provide.
Verified empirically before writing any of this.

Here the tag lives only in the session agent's memory, beside the parent seeds
it already holds, with the same TTL discipline — and in the API process's memory
for the API. Nothing derived from the factor reaches disk, asserted by a test
that scans every file in the app directory for the tag, and confirmed on a live
install. No file format or interop changes; only where the live session lives.

Other properties the tests pin:
  - a locked partition refuses reveal rather than deriving from the stub, which
    would return a plausible wrong secret
  - locking the vault drops the high-risk grant, which is scoped to it
  - the grant expires on its own clock, typically much shorter than the seed's
  - unlock is owner-gated: a scoped token cannot reach it
  - the tag is absent from the audit log, which records only that an unlock
    happened
  - the factor comes from the environment, never argv
  - factor-set refuses to replace an existing factor, since a new partition key
    would make an existing partition permanently unreadable
  - migrate writes the partition BEFORE the index, so a crash between them
    cannot leave stubs pointing at records that were never stored

Approval gates port straight across: one-shot (or N-use) authorizations for
export / reveal_parent_seed / private_key_retrieval, consumed under the store
lock so two callers cannot both spend the last use, with every failure mode
getting its own reason string matching Python's. A corrupt store reads as empty,
which fails closed.

API: /api/v1/high-risk/{status,unlock,lock} are real rather than 501. Unlock
needs the bearer token, the master password header AND the factor header; a
wrong factor gets one indistinguishable reason so probing cannot tell failures
apart.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN

js/packages/cli/src/capabilities.ts

@@ -88,6 +88,32 @@ export function capabilities(): Record<string, unknown> {
       locked_status: 423,
       unported_status: 501,
     },
+    high_risk: {
+      commands: [
+        "agent high-risk factor-set/status/unlock/lock/migrate",
+        "POST /api/v1/high-risk/unlock|lock",
+        "GET /api/v1/high-risk/status",
+      ],
+      kinds: ["ssh", "pgp", "seed", "nostr", "managed_account"],
+      // The partition file and key envelope are byte-compatible with Python,
+      // so a partition made by either implementation opens in the other.
+      interop: "file formats shared with the Python implementation",
+      // Where this port DIVERGES, and why. Python records the unlock in
+      // agent_high_risk_unlock.json including the partition key tag, from
+      // which the partition's encryption key is derived — so during any
+      // Python session the partition is readable from disk with no factor.
+      // Here the tag lives only in the agent's memory (or the API process's).
+      session_storage: "in-memory only; the partition key tag never reaches disk",
+      factor_env: "SEEDPASS_HIGH_RISK_FACTOR",
+      api_factor_header: "X-SeedPass-High-Risk-Factor",
+    },
+    approvals: {
+      commands: ["agent approval issue/list/revoke"],
+      actions: ["export", "reveal_parent_seed", "private_key_retrieval"],
+      // An approval is not a credential: it authorizes an action for a caller
+      // that must ALSO be otherwise authorized.
+      semantics: "one-shot (or N-use) authorization, consumed at action time",
+    },
     audit: {
       commands: ["agent audit-verify", "agent audit-tail"],
       chain: "HMAC-SHA256(prev_sig + canonical_payload), keyed by KEY_INDEX",
@@ -105,10 +131,9 @@ export function capabilities(): Record<string, unknown> {
       // Python-derived state, recomputed on load. Carried through verbatim by
       // the TS port so a Python profile round-trips, but not computed here.
       "index0/atlas (preserved verbatim on read/write, never recomputed)",
-      // Deliberate: agent approval gates, high-risk partitions, job profiles
-      // and recovery split. The session agent's scoped tokens cover the
-      // automation cases; these add a second authorization model.
-      "agent approval gates, high-risk partitions, job profiles, recovery split",
+      // Deliberate: agent job profiles and recovery split. The session
+      // agent's scoped tokens cover the automation cases these serve.
+      "agent job profiles and recovery split",
       // Deliberate: the TS interactive mode follows Python's legacy v1 menu
       // tree. See docs/tui_v2_cutover_decision.md.
       "Python's v2/v3 Textual TUIs (interactive mode follows the legacy v1 menus)",