dooplex-offsite: Vaultwarden (the password manager) rides the nightly encrypted copy (R-923); R-923 filed (operator finding); R-922 ruling A recorded

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

scripts/CHANGELOG.md

@@ -1,3 +1,16 @@
+## 2026-10-09 (afternoon) — dooplex-offsite carries the password manager too (R-923)
+
+- `felhom-dooplex-offsite`: a new step runs Vaultwarden's own `vaultwarden backup` (SQLite `VACUUM INTO`, consistent
+  while it runs) in its pod, copies that one file out and removes it, plus `rsa_key.pem` and (when they exist)
+  `attachments/`, `sends/`, `config.json` — Vaultwarden's backup guidance. Refuses on a failed backup command, an
+  unexpected file name, a link in the archive, a failed `integrity_check`, or no user; the backup file is removed even
+  on refusal. New metric `felhom_dooplex_offsite_last_success_vaultwarden_users`.
+- `felhom-dooplex-offsite-restore-test`: checks the Vaultwarden copy — integrity, users = `USERS`, items > 0 (row
+  counts only, never contents).
+- 6 new tests (26 total), green with GNU tools, BusyBox tools and the fake `sqlite3`; red-proofs in
+  `audits/dooplex-survival-2026-10-09/vaultwarden/red-proof.txt`. The tests found a real defect before any live run:
+  the optional-file listing returned non-zero when the last optional file was absent.
+
 ## 2026-10-09 — dooplex-offsite: Gitea + DooPlex's secrets leave DooPlex nightly, encrypted (R-232 (b), (h))
 
 - New `scripts/dooplex-offsite/`: `felhom-dooplex-offsite` (daily 00:20) copies the newest complete `gitea.dump`