Implement the Connection Vault protocol layer (phases A-C)

connection-vault.md 5-13 as code, with the implementation-time decisions
recorded in a new section 18 and vault-ux.md holding the agreed UX
walkthroughs as the authorization layer's acceptance criteria.

Capsules gain paired optional fields connection_vault_root and
vault_sudo_key (both or neither, validated); registration mints them,
login/change-password/recovery carry them forward, and
enableConnectionVault is the phrase-gated migration for existing
accounts -- recovery capsule written first, fail closed, idempotent by
reusing roots found in either capsule so a partial failure can never
mint twice and strand records.

src/vault/ holds the finalized key hierarchy (HKDF/ScalarExpand
constants pinned by test vectors that must only ever be reverted, never
updated), per-connection encrypted records signed by a derived vault
identity with the capsule JCS+padding+AES-GCM pipeline and shared
buckets so record types are indistinguishable by size, the NWC profile
with lossless URI parse/export, relay sync reusing the publish-and-
verify quorum bar, and per-record high-water marks so a stale replica
is withheld and reported rather than silently resurrecting a revoked
credential.

The two-tier model makes sudo mode cryptographically real: personal-
tier record keys require vault_sudo_key as HKDF input, VaultSession
holds it only inside an enableSudo/endSudo window (wiping on the way in
and out), and outside a window personal records are invisible -- the
same trial-decrypt returns null, not an error. The app-facing API is
structurally blind to the tier by construction.

118 tests passing, including four end-to-end scenarios against mock
relays: clean-device restore, password-change carry, legacy-account
migration (wrong phrase refused), and rollback detection.

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01CMr9Yt8SYmZcfgrg3CV2G1

CHANGELOG.md

@@ -6,6 +6,24 @@ site with its own vendored copy (see "Updating your integration" in
 sitting on an older vendored copy is missing a fix or behavior change it
 would plausibly want. Newest first.
 
+## 2026-07-30
+
+- **Connection Vault protocol layer in `@bitlogin/core`** (`src/vault/`):
+  encrypted per-connection records signed by a derived vault identity, the
+  finalized §CV6 key hierarchy with pinned test vectors, the NWC credential
+  profile (lossless URI parse/export), relay sync with quorum readback and
+  per-record rollback detection, and the two-tier model — connectable
+  records vs sudo-gated personal records (`connection-vault.md` §18).
+- **Capsules gained paired optional fields** `connection_vault_root` and
+  `vault_sudo_key` (both or neither; validated). Registration mints them for
+  new accounts; `enableConnectionVault` is the phrase-gated, fail-closed,
+  idempotent migration for existing accounts. Login, password change, and
+  phrase recovery all carry them forward.
+  **Integration caveat:** a site on an OLDER vendored widget that performs a
+  password change will rebuild the credential capsule WITHOUT these fields,
+  stranding connectable records until a phrase ceremony repairs them —
+  update vendored copies before enabling the vault for users.
+
 ## 2026-07-21
 
 - **Fix: registration/login could fail quorum if a single built-in relay was