feat(vault): per-key hierarchy with key management and identity login (R1-R3)

docs/AI-driver/02-auth.md

@@ -26,10 +26,13 @@ Auth state is client-side only: Redux `auth` slice + optional localStorage.
 - `src/lib/steem/server.ts` — `generateChallenge`, `verifyChallengeSignature`, `getKeyType`
 - `src/components/auth/login-form.tsx` — **the only live login UI** (login page, header modal,
   re-auth modal). Contains: username normalization, required-authority gate (#338), posting-key
-  restore from localStorage, remember-me writes.
-- `src/hooks/use-auth.ts` — read-only consumption (`username`/`isAuthenticated`/`logout`).
-  ⚠️ Its `login`, `useRequireAuth`, `usePrivateKey` are dead, behavior-rotted code (no
-  normalization, no #338 gate). Do not call them; candidate for deletion.
+  restore from localStorage, remember-me writes. Since vault R3 the exported `LoginForm` is a
+  signing-mode DISPATCHER: the classic flow above is the module-private `PrivateKeyLoginForm`
+  (body unchanged); a positively read Vault Mode renders `vault-login-form.tsx` (identity
+  selection — no challenge/login at all), see `09-vault.md` invariant 21.
+- `src/hooks/use-auth.ts` — read-only consumption (`username`/`isAuthenticated`/`logout`) plus
+  `useActiveSigningKey()`. (The old `login`, `useRequireAuth`, `usePrivateKey` halves were
+  deleted in #343; `LoginForm` is the only login entry point.)
 - `src/lib/auth/browser-storage.ts` — localStorage contract (see below).
 - `src/lib/store/slices/auth.ts` — holds credentials incl. private keys; sanitized in DevTools.
 
@@ -97,7 +100,8 @@ mainnet blocks. This is consensus truth, not wallet policy — build key-selecti
   where "hierarchy" does not transfer.
 - Least privilege when the client picks a key: prefer the lowest authority the chain accepts
   for that op. The claim banner (#378) resolves
-  session posting → device-remembered posting (chain-verified) → session active → session owner
+  session posting → device-remembered posting (chain-verified; privateKey sessions only — a
+  vault session skips it, see 09-vault.md invariant 21) → session active → session owner
   → re-auth dialog. Re-auth dialog copy keeps asking for the minimal key (posting key /
   password) as a habit, while accepting higher keys, which the chain honors.
 - `LoginForm.requiredAuthTypes` (#338) models exactly the chain signing hierarchy:
@@ -131,13 +135,18 @@ route does this; copy that pattern, do not let a parse throw reach the outer cat
   console output.
 - Redux DevTools sanitizers (`store/index.ts`) cover `auth/setCredentials` — **the only action
   allowed to carry key material**. If you invent a second action that carries keys, you must
-  extend `devActionSanitizer` (there is no guard that reminds you).
+  extend `devActionSanitizer` (there is no guard that reminds you). (`auth/setVaultIdentity`,
+  vault R3, carries only a username by contract and nulls every key field.)
 - localStorage (`browser-storage.ts`): **only** `username` + optional posting key
   (`REMEMBERED_*` keys). Never active/owner keys. Note the module only has get/clear — the actual
-  `setItem` is inlined in `login-form.tsx:308-326`; keep new writes inside that same audit surface
+  `setItem` is inlined in `login-form.tsx` (`PrivateKeyLoginForm`'s remember-me branch); keep new
+  writes inside that same audit surface
   or extend the module properly.
-- Logout (`useAuth().logout`): fires `/api/auth/logout` (CSRF'd no-op on the server) and
-  unconditionally clears Redux + both localStorage keys regardless of the HTTP result.
+- Logout (`useAuth().logout`): for privateKey sessions, fires `/api/auth/logout` (CSRF'd no-op
+  on the server) and unconditionally clears Redux + both localStorage keys regardless of the
+  HTTP result. Vault sessions (`sessionKind: 'vault'`, R3) never logged in server-side: their
+  logout clears ONLY Redux — no server call, and the Legacy remembered keys are neither read nor
+  removed (deliberate; do not "unify" the two paths).
 - Re-auth (#338): `LoginForm` accepts `requiredAuthTypes` and enforces the authority hierarchy
   owner > active > posting (memo separate) — which mirrors the chain's signing fallback, see
   the "Steem authority semantics" section above. Modal consumers (change password, recovery,

docs/AI-driver/06-frontend.md

@@ -81,8 +81,10 @@ canonical lowercase.
   fallback, see the "Steem authority semantics" section in 02-auth.md; do NOT consult
   `get_required_signatures`, it is strict per-class and misleads). Reference implementation:
   `ClaimRewardsBanner.handleClaim` (#378) resolves session posting → device-remembered posting
-  (chain-verified) → session active → session owner → re-auth dialog, and only shows the
-  keyless hint when NO signing key exists.
+  (chain-verified; privateKey sessions only — skipped when `sessionKindOf(auth)` is `'vault'`,
+  09-vault.md invariant 21) → session active → session owner → re-auth dialog, and only shows
+  the keyless hint when NO signing key exists. Never copy the device-remembered step into a
+  path a vault session can reach; vault signing is the per-key password path (A6).
 
 ## Legacy-parity watchlist (verified drifts from `wallet-legacy`)