Protect personal memory with per-account encryption and explicit background access

The user wants useful remembered facts (vehicle registration, verified MOT expiry, preferences) without implying that other people's data is safe merely because it lives on this server.

Current source findings: internal/notes persists account-keyed records through ordinary JSON and indexes title/text in the owner-scoped search index. Google standing grants persist refresh tokens. Mail has separate instance-key encryption, not a user-only vault. Account scoping is authorization, not encryption; disk encryption alone does not protect from a running server with access.

Proposed default: per-account random data encryption keys wrapped by a separately managed instance key, authenticated encryption bound to owner/record kind/ID/version, access checks before decryption. This supports explicitly authorized offline work and is not end-to-end encryption: the operator/server can still decrypt. Do not claim otherwise.

A true user-unlocked vault is a separate mode/design: client-controlled unlock material, expiry, multi-device access and recovery. When locked, the assistant cannot inspect its contents or refresh encrypted Google credentials. Existing email/SMS entry points and background briefs cannot silently unlock it. A reminder can still fire if its minimal schedule/delivery record is separately authorized; it does not need ongoing access to the complete personal vault.

• Inventory private stores and every derived copy: notes, threads, task payloads/results, events, Google refresh tokens, search indexes/FTS, attachments, logs and backups.
• Define and implement a common account-bound encrypted store, external key provisioning, rotation, restart recovery and failure behavior. Never generate a replacement key over unreadable encrypted data or fall back to plaintext.
• Plan migration and rollback without plaintext duplicate indexes/backups or silent data loss. Treat deletion across replicas/backups explicitly.
• Retrieve only relevant remembered facts for a task. Separate user-provided facts from observations; keep source, checked-at time and expiry. Expose review/correction/deletion using existing sparse surfaces.
• Save only explicit facts or verified observations needed for a user's goal, not speculative inferences. Clearly acknowledge remembered vehicle details and reminders.
• Define minimal background task access independent of broad interactive access. A fixed MOT reminder should not require an LLM or Google mailbox read at firing time.
• Finish Google controls: task-specific older-mail authorization, bounded background reads, selected Drive material, minimal calendar fields and non-content access receipts. Gmail's first seven-day enforcement change is #1809.
• Assess user-unlocked mode separately, including what genuinely stops working while locked. Do not retrofit login-password-derived encryption as a shortcut (passkeys/Google sign-in/reset/recovery matter).

No encryption migration or user-only vault is implemented by this issue. Encryption at rest also does not prevent plaintext tool results from being sent to the configured cloud model; data minimization remains necessary.

Start with internal/notes and the existing mail instance-key encryption, then inventory the private stores and derived copies listed in the issue, including Google refresh tokens, indexes, logs and backups. Read #1809 for the Gmail enforcement context. Done means the scope, key management, migration and rollback behavior, background-access boundaries, and separate user-unlocked mode are defined without claiming that server-side encryption is end-to-end.