feat: mirror the diary to Proton Drive as a device

The data directory is the whole diary, and until now keeping a copy of it
was someone's manual job. The server can now register itself in Proton
Drive as a device — its own sync root, next to the desktop clients — and
keep that folder equal to DIARY_DATA_DIR, encrypted client-side by the
same Rust SDK the Linux client uses.

One interactive `narl-diary proton-login`, then nothing prompts again.
The stored session carries the tokens, the mailbox password (the key
chain is rebuilt from it on every start) and the account key salts, which
have to be captured at login: `core/v4/keys/salts` needs the `locked`
scope, and only a password-login token has it. Refresh tokens are
single-use, so every rotation is written back before it can be needed.
It lives as a 0600 file next to the database, on the same volume as the
data it protects; `--features keyring` puts it in the OS keyring instead,
for hosts that have a Secret Service.

The mirror is one-way and change-driven: writes mark the diary dirty and
it is mirrored once the writing stops, with an interval as the backstop —
an hour of writing is one backup, not sixty. `diary.db` goes up as a
VACUUM INTO snapshot, so it is a real point in time rather than a file
copied out from under a writer, and as a new revision each time, so
Proton keeps the older ones. Uploads are immutable, so they are written
once and skipped by size afterwards. Deletions do not propagate unless
asked: a backup that forgets on command is one accident away from being
no backup at all.

Identification follows Proton's third-party rules — an honest
`external-drive-narl_diary@<version>-alpha`, the disclosure printed
before any credential is asked for, and remembered folder uids instead of
walking the tree every run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D5Gk8FPkRXu1e6Nj2BCRE1

migrations/0003_backup.sql

@@ -0,0 +1,20 @@
+-- Bookkeeping for the Proton Drive mirror. It lives in the diary database so a
+-- backup and the state describing it can never drift apart across a restore:
+-- restore the database, and the mirror knows exactly what it already holds.
+
+CREATE TABLE backup_state (
+    key   TEXT PRIMARY KEY,
+    value TEXT NOT NULL
+) WITHOUT ROWID;
+
+-- One row per file that exists remotely. `path` is the path inside the device
+-- root ('diary.db', 'uploads/<uuid>'), `node_uid` the Drive '<volume>~<link>'
+-- pair, so an unchanged file is skipped and a changed one becomes a new
+-- revision of the node that is already there.
+CREATE TABLE backup_files (
+    path        TEXT PRIMARY KEY,
+    node_uid    TEXT    NOT NULL,
+    hash        TEXT    NOT NULL,
+    size        INTEGER NOT NULL,
+    uploaded_at INTEGER NOT NULL
+) WITHOUT ROWID;