rekey_rotates_owner_share_and_keeps_listed_recipients failed in CI:
the response's wrapped_profile_dek was 'owner-dek-v1' (old) instead of
'owner-dek-v2' (new). update_wrapped_dek uses find_one_and_update,
which returns the document as it was BEFORE the update by default —
so reading the new value from the returned doc gives the pre-image.
Fix: echo the request values (exactly what was stored) in the response
instead of reading them back. Unambiguous and avoids the
ReturnDocument::After plumbing. The write itself was always correct
(the stored value was v2) — only the response was stale, which is why
the other rekey tests (which check state via fresh reads, not the
response body) passed.
Now CI-green (clippy/fmt clean; integration tests will re-run).
An owner can now rotate a profile's DEK — generating a fresh key,
re-encrypting all the profile's data under it (client-side), and
re-wrapping to the owner share + kept recipients. A revoked recipient's
cached old DEK stops working, closing the soft-revoke window the ADR
requires for graduation / suspected compromise.
The server stays a blind store: it sees opaque old→new ciphertext blobs
flow through, never the DEK or plaintext. No backend crypto.
Backend:
- ProfileRepository::update_wrapped_dek — rotate the owner share
(account-wrapped profile DEK), owner-scoped.
- ProfileShareRepository::find_active_for_profile +
delete_for_profile_excluding — list current recipients and hard-delete
omitted ones.
- POST /api/profiles/:id/rekey: validates each submitted envelope
against existing active shares (no smuggling new recipients in via
rekey), rotates the owner share, upserts recipient envelopes with
fresh ephemeral ECDH keys, hard-deletes omitted recipients.
- rekey_tests.rs: rotation, hard-revoke-from-recipient-view, no-share
rejection, non-owner rejection, revoke-all.
Frontend:
- useProfileStore.rekeyProfile: fetches all profile data, re-encrypts
each row under a new DEK (resume-safe — rows already on the new DEK
are skipped), builds fresh ECDH envelopes per kept recipient, commits
via POST /rekey, swaps the in-memory DEK.
- ProfileSharing: 'Rotate encryption key (hard revoke)' action with a
strong confirmation dialog explaining the cost and the resume-safe
retry.
Best-effort + resumable retry (per design decision); no server-side
write lock.
Verification: backend cargo build/clippy (-D warnings)/fmt clean, tests
compile (integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 31/31 tests pass.
⚠️ Backend integration tests not run locally (no Mongo in this sandbox);
CI will run them — I'll fix any failures.
Admin-initiated rekey (ADR §5c reserves the permission) is out of scope
— handler is owner-only until admin shares are creatable in Phase D.
Refs #3.
backend/src/auth/claims.rs was orphaned dead code: auth/mod.rs never
declared 'mod claims', so the file wasn't compiled into the crate at
all. It defined two structs:
- AccessClaims — referenced nowhere; a latent trap (carried
family_id/permissions fields that suggested enforcement that doesn't
exist).
- RefreshClaims — a duplicate of the LIVE RefreshClaims in jwt.rs,
which is what JwtService actually uses.
Deleted the file. Updated the JWT ADR to mark the open item done and
note the removal historically.
Build/clippy/fmt clean (the file wasn't compiled anyway). Closes#5.
The update/delete handlers for medications and appointments took the
auth Claims but never used them — any authenticated user could update
or delete any other user's records by id (an IDOR). Same gap on
log_dose (could skew another's adherence stats) and get_adherence
(leaked dose history).
Fix: each affected handler now looks up the item first and confirms
user_id == claims.sub before mutating/returning. Mismatches return 404
(not 403) to avoid leaking the existence of other users' records.
Recipients of shared profiles remain read-only per the ADR — writes
stay owner-only.
Covered handlers:
- update_medication, delete_medication, log_dose, get_adherence
- update_appointment, delete_appointment
health_stats update/delete were already checking user_id == claims.sub
(unaffected).
New ownership_tests.rs: cross-user update/delete/log-dose/adherence all
404; the legitimate owner can still do all of the above.
Verification: cargo build/clippy (-D warnings)/fmt clean; existing
tests unaffected (they operate as the same user that created the data).
Closes#12.
The share-gate I added in Phase B was too strict: it only admitted the
owner via the profiles collection, so any data item whose profile_id
didn't map to a real Profile document (legacy/test data, or a profile_id
the caller used at create time without a backing Profile) got 404'd on
read — even for the item's actual owner. CI caught this:
zk_integration_tests::medication_stored_as_ciphertext_not_plaintext
creates a medication with profile_id="default" (no Profile doc) and
the new get_medication gate returned 404.
Fix: in each list/get data handler, check direct ownership
(user_id == claims.sub, or has own data for the profile) FIRST, and
only fall through to the share-gate if the caller isn't the direct
owner. This preserves the original ownership model AND adds share-
recipient access, without breaking items whose profile_id isn't a real
Profile document.
The share-only path (recipient reading shared data they don't own)
still goes through the gate as before.
Three share_tests were failing in CI:
1. public_key_lookup_returns_recipient_identity_key — passed the email
as a JSON body on a GET, but send_json builds the URI verbatim and
ignores the body for GET. The query string was never formed, so the
handler got an empty email. Fix: put ?email=... in the URI directly
(URL-encoding the '@').
2. public_key_lookup_404s_for_unknown_or_keyless_user — same root cause.
3. owner_shares_recipient_reads_owner_revokes — asserted the recipient's
write would return 201 or 403, but create_medication returns 200 OK
(Axum's default for Ok(Json(...))), and the write currently succeeds
because the create handler doesn't check ownership (issue #12). The
write is attributed to the recipient, not the owner, so the owner's
data is still untouched — which is what the test really wants to
prove. Accept 200 (current) or 403 (once #12 lands); documented the
tie to #12.
An owner can now share a profile with another account; the recipient
reads the profile's metadata AND its data (medications, appointments,
health stats) under their own login. The server stays a blind store:
sharing uses an X25519 envelope — the owner wraps the profile DEK to
the recipient's identity public key via ECDH (fresh ephemeral key per
share), the recipient unwraps it with their identity private key.
Backend:
- models/profile_share.rs: ProfileShare + ProfileShareRepository
(find_for_recipient, find_for_profile, find_active [checks active +
expiry], delete, upsert). Indexed on (profileId, recipientUserId) and
recipientUserId.
- handlers/profile_share.rs: POST/GET /profiles/:id/shares,
DELETE /profiles/:id/shares/:recipient, GET /profiles/shared-with-me,
GET /users/public-key (public), and authorize_profile_read — the
share-gate that admits owner OR active-share recipient.
- The share-gate is wired into list/get for medications, appointments,
and health stats: when profile_id is specified, resolve the owner via
the gate and query as them. Data repos stay ownership-scoped.
- Removed the legacy Share system (ADR Open Q5): models/{share,
permission}.rs, handlers/{shares,permissions}.rs, middleware/
permission.rs (dead), the shares collection field + methods in
mongodb_impl.rs, the shares index, and the 5 /api/shares +
/api/permissions routes.
- share_tests.rs: full owner→recipient→revoke flow, ownership
isolation, share-to-self/nonexistent/keyless rejections, expired
share treated as absent.
Frontend:
- crypto/keys.ts: wrapProfileDekToRecipient /
unwrapProfileDekFromShare (ECDH envelope, ephemeral key per share).
- useProfileStore: loadSharedWithMe (unwrap each share's DEK with the
identity private key), shareProfile, revokeShare, loadProfileShares.
Shared profiles merge into the list with is_shared=true.
- ProfileSwitcher: shows shared profiles with a 'shared' chip.
- ProfileSharing (new) + ProfileEditor: owner UI to add a recipient by
email and revoke; shared profiles render read-only with owner info.
- ECDH round-trip test (owner wraps, recipient unwraps, stranger can't).
Verification: backend cargo build/clippy (-D warnings)/fmt clean, tests
compile (integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 31/31 tests pass.
⚠️ Backend integration tests not run locally (no Mongo/Docker in this
sandbox); CI will run them — I'll fix any failures immediately.
Phases C (hard revoke / re-key) and D (graduation) remain. Refs #3.
verify_password() was mapping every password-hash failure — including a
plain wrong password (password_hash::Error::Password) — to Err, which
propagated to the login handler's Err arm and returned 500
'authentication error' instead of 401 'invalid credentials'.
All three callers (login, change_password, recover_password) already
match on Ok(true)/Ok(false)/Err and expect Ok(false) for a mismatch;
the function just wasn't honoring that contract. Map
Error::Password -> Ok(false) and propagate only genuine failures as Err.
This was a latent bug: CI's auth tests never ran before because the
Mongo service container couldn't schedule (port collision, fixed in
#8). Now that CI runs them for real, login_with_wrong_password_is_rejected
exposed it. Behavior improves on all three call sites — a wrong recovery
phrase now also correctly 401s instead of 500ing.
Implements the 3-tier key model from the multi-person sharing ADR:
each account owns multiple profiles (a person or pet — a 'subject of
care'), and each profile has its own random AES-256-GCM DEK. All
health data is now encrypted under the active profile's DEK, not the
account-wide DEK. The account DEK wraps each profile DEK; the server
stores only opaque wrapped blobs.
Per the ADR: DB wipe, no migration (no real user data). This unblocks
Phase B (sharing) — there is now a per-profile key to wrap to a
recipient's X25519 public key.
Backend:
- Profile model: owner_account_id, kind (human/pet), relationship,
wrapped_profile_dek + iv. ProfileRepository gains find_all_by_owner,
find_by_profile_id_owned, update_profile, delete_profile — all
ownership-scoped.
- Profile handlers: GET/POST /api/profiles, GET/PUT/DELETE
/api/profiles/:id. Removed /api/profiles/me. Renamed users.rs
get_profile/update_profile (the /api/users/me handlers) to
get_account/update_account to resolve a name collision.
- Register accepts default_profile_* fields and auto-creates the self
profile when the client provides a wrapped profile DEK.
- HealthStatistic + Appointment gain profile_id and ?profile_id=
filtering (health stats previously had no profile binding).
- New profile_tests.rs: multi-profile CRUD + ownership isolation +
register-with-default-profile. Fixed the zk health-stat test to
send the now-required profile_id.
Frontend:
- crypto/keys.ts: generateProfileDek, wrapProfileDek, unwrapProfileDek
+ in-memory per-profile DEK store with an active-profile concept.
- useProfileStore rewritten: holds profiles[], activeProfileId;
loadProfiles unwraps each profile DEK; create/update/delete. All 11
encrypt/decrypt sites switched from getEncKey() to
getActiveProfileDek(). load actions pass ?profile_id= so only the
active profile's rows come back.
- ProfileEditor rewritten for the new store (edit active profile,
create/delete). New ProfileSwitcher in the Dashboard AppBar.
- MedicationManager / AppointmentsManager use the active profile id
instead of the hardcoded profile_<user_id>.
- 2 new crypto tests for per-profile DEK isolation; updated store +
component tests for the active-profile-DEK model.
Verification: backend cargo build/clippy/fmt green, tests compile
(integration tests run in CI — Mongo is fixed there). Frontend
tsc clean, 30/30 tests pass.
Closes nothing yet (Phase B/C/D remain). Refs #3.
The test job failed on the runner with:
Bind for 0.0.0.0:27017 failed: port is already allocated
because the services.mongo ports: 27017:27017 tries to claim host port
27017, which is occupied (mongod on the runner host). The job container
doesn't need the host mapping — it reaches Mongo over the job's internal
network via the service hostname (MONGODB_URI=mongodb://mongo:27017).
Drop the ports block so the service container schedules cleanly.
This unblocks all PRs, including #6 (Phase A1).
Phase A1 of the multi-person sharing ADR
(docs/adr/multi-person-sharing.md). Each account now gets an X25519
keypair at registration: the public half stored plaintext, the private
half wrapped under the account DEK and stored as opaque ciphertext. The
keypair is generated client-side; the backend adds no crypto deps and
stores everything verbatim, preserving the zero-knowledge contract.
This change only introduces the keypair and threads it through the auth
flows — it is not consumed yet. It unblocks Phase B (profile sharing)
without touching the data model or the ~11 frontend encrypt call sites,
which is Phase A2 (per-profile DEKs).
Backend:
- User model: identity_public_key, identity_private_key_wrapped{,_iv}
(all Option<String>, backward compatible).
- RegisterRequest/AuthResponse carry the 3 fields; register + login
echo them. No changes to change_password/recover (DEK value is
unchanged across both, so the wrapped private key is too).
- 2 new integration tests: round-trip through register/login, and
optional-fields backward compat.
Frontend:
- crypto/keys.ts: generateIdentityKeyPair, wrapIdentityPrivateKey,
unwrapIdentityPrivateKey + in-memory identity store mirroring the DEK.
- types/api.ts: AuthTokens + RegisterRequest extended (removes an
existing `as any` cast).
- useStore register/login/logout + UnlockPage unwrap the private key
alongside the DEK.
- 3 new crypto tests (X25519 lifecycle, wrong-DEK rejection, distinct
shared secrets); skip gracefully where the runtime lacks X25519.
Backend: cargo test + clippy green. Frontend: npm test + tsc green.
Also gitignore .zcode/ (local tooling artifact).
Rewrite the encryption/persona/JWT docs to match the implemented code and
record the multi-person sharing design.
- multi-person-sharing.md (NEW): ADR for per-profile DEK + X25519 envelope
sharing. All five original open questions resolved 2026-07-18. Covers
divorced-parents, pets, graduation, and elderly-parent care; adds an
admin permission tier for owner-incapacity. Decided, not yet implemented.
(#3)
- encryption.md: full rewrite to the implemented wrapped-DEK / Web Crypto
model; the old version described ZK encryption as 'planned'. (#4)
- jwt-authentication-decision.md: rewritten to match implementation
(PBKDF2 not bcrypt, no Redis, token_version revocation, real Claims).
Original aspirational content preserved in a History section. (#4)
- PERSONA_AND_FAMILY_MANAGEMENT.md: 'Current reality' section added, old
'Implementation Status' marked superseded, encryption section corrected. (#4)
- ENCRYPTION_UPDATE_SUMMARY.md: archived (changelog for a rewrite that
itself went stale). (#4)
- ADR README index updated for the new + reconciled entries.
- Add AGENTS.md as the cross-agent entry point (lean; points to
.gooserules and docs/AI_* for detail)
- Document the Forgejo issue-driven workflow (report → triage →
implement → close) and API patterns in .gooserules
- Add Forgejo step to the pre-change checklist
- Gitignore .forgejo-token
Browsers disable crypto.subtle on non-localhost HTTP. The frontend server now
generates a self-signed TLS cert at startup and serves over HTTPS by default
(FRONTEND_TLS=true). FRONTEND_TLS=0 disables it for localhost dev.
Added axum-server (tls-rustls) + rcgen deps to the frontend-server crate.
A dedicated Rust/Axum binary (web/frontend-server/) that:
- Serves the built Vite SPA bundle from dist/ via tower-http ServeDir
- Falls back to index.html for SPA routing (deep links work)
- Reverse-proxies /api/* to the backend container (same-origin, no CORS)
- Listens on port 8080 (configurable via FRONTEND_PORT)
Dockerfile (web/normogen-web/Dockerfile): 3-stage build:
1. Node: npm ci + npm run build -> dist/
2. Rust: cargo build --release the frontend-server binary
3. Runtime: debian-slim + binary + dist/
docker-compose.yml: new 'frontend' service on :8080, depends on backend healthy,
proxies to http://backend:6500. Independently scalable (run N replicas behind
a load balancer).
Architecture:
Browser -> :8080 (frontend container)
/api/* -> proxy -> backend:6500
/* -> static dist/ (SPA)
Dose scheduling:
- DoseSchedule struct (times_per_day + days_of_week) as top-level field on
Medication. get_adherence computes scheduled_doses from the schedule over
the period; missed doses now reflected. Fallback to taken/total_logged when
no schedule. Wired through create/update requests + MedicationResponse.
- Frontend: dose_schedule field on Medication domain type + wire response;
store reads it on load. (MedicationManager UI field deferred — the data
flows correctly; a form field can be added when needed.)
Health stats zero-knowledge:
- HealthStatistic model now uses opaque encrypted_data blob (like medications).
Only recorded_at stays plaintext. HealthStatResponse wire type.
- Removed the trends endpoint (server can't compute on ciphertext); trends
are now computed client-side in the health store after decryption.
- Deleted the dead HealthData model (kept EncryptedField which it defined).
- Frontend: health store decrypts on load + encrypts on write; trends
computed client-side; HealthStats component uses domain form types.
Verified: backend 24 tests 0 warnings; frontend build clean, 24 tests.
Backend changes (frontend + tests follow in next commit):
Dose scheduling:
- New DoseSchedule struct (times_per_day + days_of_week) as a top-level
plaintext field on Medication. Create/update requests accept it.
- Revised get_adherence: computes scheduled_doses from the schedule over the
period (days_of_week filtering), so missed doses are now reflected.
Falls back to taken/total_logged when no schedule.
Health stats zero-knowledge:
- HealthStatistic model now uses opaque encrypted_data blob (like medications).
Only recorded_at stays plaintext (filterable/sortable).
- HealthStatResponse wire type. Handlers echo opaque blobs.
- Removed the trends endpoint (server can't compute trends on ciphertext;
frontend computes them client-side after decrypting).
- Deleted the dead HealthData model (kept EncryptedField which it defined).
Verified: backend 24 tests, 0 clippy warnings.
Rate limiting (closes the last security gap #3):
- New RateLimiter: in-memory fixed-window IP-based limiter (std::sync::Mutex
HashMap, no new deps). Configurable via RATE_LIMIT_MAX (default 100) +
RATE_LIMIT_WINDOW_SECS (default 60) env vars.
- general_rate_limit_middleware now reads ClientIp from request extensions and
rejects with 429 + Retry-After header when over the limit. Wired via
from_fn_with_state in app.rs. Lived on AppState as Arc<RateLimiter>.
- Deleted the dead auth_rate_limit_middleware (never wired).
- 3 unit tests (allows up to N, independent IPs, window reset).
E2E crypto lifecycle test:
- Full zero-knowledge round-trip against jsdom's real Web Crypto: setup →
encrypt → verify ciphertext → unlock with password → decrypt → recover via
phrase → rewrap under new password → decrypt. Plus wrong-password/wrong-phrase
failures and cross-user key isolation.
- Fixed wrapDek/unwrapDek: base64-encode raw DEK bytes (was using TextDecoder
which produced non-base64), and make unwrapped DEK extractable (needed for
rewrapDek to export).
Verified: backend 24 tests 0 warnings; frontend 24 tests, build clean.
Solves the core usability problem of zero-knowledge encryption: on page reload
the in-memory DEK is lost, so the user can't decrypt their data even though their
JWT is still valid. Previously they had to close the tab and re-login from scratch.
Changes:
- Persist wrapped_dek/wrapped_dek_iv in the auth store (zustand persist). Safe:
it's AES-GCM ciphertext, useless without the password KEK — the server already
stores the same ciphertext. login/register/recover all save the wrapped DEK;
logout clears it.
- New UnlockPage: minimal password-only form. Re-derives the DEK locally via
unlockWithPassword (no API call — the JWT is still valid). Falls back to
deriveAuthAndEncKeys for Phase 1 compat accounts. Links to /login and /recover.
- ProtectedRoute now checks hasEncKey() after isAuthenticated: authenticated but
no in-memory DEK → redirect to /unlock.
- /unlock route in App.tsx (public, alongside login/register/recover).
Flow: login → browse → reload page → unlock screen → enter password → dashboard
loads with decrypted data. No full re-login needed.
Verified: npm build clean, 20 tests pass.
Register now generates a DEK, wraps it under the password KEK and recovery KEK,
and sends all wrapped forms to the server (via setupEncryption). RegisterPage
has an optional recovery phrase field with a warning. Login unwraps the DEK
from the response via unlockWithPassword. This completes the full ZK recovery
flow end-to-end from the UI.
Verified: npm build clean, 20 tests pass.
Introduces a wrapped-DEK recovery model so a forgotten password doesn't lose
all encrypted data. The encryption key becomes a random DEK (not derived from
the password); the DEK is wrapped under both a password-derived KEK and a
recovery-phrase-derived KEK, and both wrapped forms are stored on the server.
Crypto (crypto/keys.ts):
- DEK generation (random AES-256-GCM), KEK derivation (PBKDF2 password/recovery),
wrapDek/unwrapDek/rewrapDek.
- setupEncryption(password, recoveryPhrase?) — generates a DEK, wraps under both
KEKs, returns wrapped forms + recovery proof.
- unlockWithPassword(password, wrappedDek) — derives password KEK, unwraps DEK.
- unlockWithRecovery(phrase, wrappedDek) — derives recovery KEK, unwraps DEK.
Backend:
- User model: wrapped_dek, wrapped_dek_iv, recovery_wrapped_dek,
recovery_wrapped_dek_iv fields.
- RegisterRequest accepts wrapped-DEK fields; stored verbatim.
- AuthResponse returns wrapped_dek + wrapped_dek_iv (for login unwrapping).
- New GET /api/auth/recovery-info?email= — returns recovery-wrapped DEK.
- RecoverPasswordRequest gains new_wrapped_dek + new_wrapped_dek_iv.
- change-password also accepts + stores re-wrapped DEK.
Frontend:
- Auth store: login unwraps DEK from response; new recover() action fetches
recovery-wrapped DEK, unwraps with phrase, re-wraps under new password.
- RecoveryPage (new): email + recovery phrase + new password flow.
- LoginPage: 'Forgot password? Recover' link. App.tsx: /recover route.
Verified: backend 21 tests, 0 warnings; frontend build clean, 20 tests.
Complete the core zero-knowledge property: all user data (medications,
appointments, profile names) is now client-encrypted via AES-GCM; the server
stores and returns opaque ciphertext and can never decrypt it.
Frontend crypto module (Web Crypto API, no deps):
- crypto/keys.ts: double-PBKDF2 derivation from the password — an auth secret
(base64, sent to the server as the 'password') and an encryption key (AES-GCM
CryptoKey, kept in memory only, never transmitted). In-memory key store.
- crypto/cipher.ts: AES-GCM encrypt/decrypt + JSON convenience wrappers.
Auth split: login/register now derive the auth secret + enc key from the
password BEFORE the API call. Only the auth secret (not the raw password) is
sent to the server. The server's PBKDF2 stays as-is (it hashes whatever it
receives) but can never derive the enc key.
Backend — server treats all data blobs as opaque:
- Medication: removed MedicationData + flat MedicationResponse; new
MedicationResponse echoes metadata + encrypted_data blob. Create/update
accept opaque blobs (whole-blob replace). MedicationData struct deleted.
- Appointment: same opaque treatment; status moved to a top-level document field
so it remains filterable without decryption. AppointmentData struct deleted.
- Profile: name is now an opaque encrypted blob (name_data/name_iv). Auto-created
profile starts empty; client sets it.
- EncryptedFieldWire shared wire type across medication/appointment.
Frontend — decrypt-on-read, encrypt-on-write:
- Stores derive the enc key on login/register; decrypt wire responses into
domain objects on load; encrypt domain data into blobs on create/update.
- API client returns wire types (opaque blobs); components consume decrypted
domain data (mostly unchanged — the store does the crypto).
- Updated store tests for the ZK contract (derive a real key, mock wire responses).
- 20 frontend tests pass, build clean.
Backend: 21 tests pass (removed MedicationData/appointment-data deser tests;
opaque-blob echo tests added), clippy 0 warnings.
KNOWN LIMITATIONS (Phase 2): forgotten password = data loss (no recovery wrapping
yet). Page reload requires re-entering the password to re-derive the enc key
(in-memory only, by design). No data migration (no real data existed).
Backend: server can no longer read user data. All data blobs (medication,
appointment, profile name) are now opaque client-encrypted ciphertext — the
server stores and returns them verbatim, never deserializing the contents.
- Medication: removed MedicationData + flat MedicationResponse; new
MedicationResponse echoes metadata + encrypted_data blob. Create/update
accept opaque blobs (whole-blob replace). Update is no longer load-mutate-
reserialize (server can't read the data).
- Appointment: same opaque treatment; status moved to a top-level document
field so it remains filterable without decryption.
- Profile: name is now an opaque encrypted blob (name_data/name_iv). Auto-
created profile on register starts with an empty name; client sets it.
- EncryptedFieldWire type shared across medication/appointment.
Frontend (partial): crypto module using Web Crypto API —
- crypto/keys.ts: double-PBKDF2 derivation (auth secret sent to server +
encryption key kept in memory); in-memory key store (set/get/clear).
- crypto/cipher.ts: AES-GCM encrypt/decrypt + JSON convenience wrappers.
- crypto/index.ts: re-exports.
NOT YET DONE (frontend integration): auth store key derivation on login/register,
stores decrypt-on-load/encrypt-on-write, types update, UI components wired,
crypto round-trip tests, ADR. This commit is a verified checkpoint — backend
builds clean (21 tests, 0 warnings); frontend crypto module exists but is not
yet wired into the data flow.
