docs: chrome/firefox CSV staging proven LIVE-VM (tmpfs + shred)

lab-provision-browsercsv.sh + csv-commit-probe.py drive the real `passwords
commit --allow-csv` path in the sandbox VM and assert the security-critical,
unattended machinery: the new-password CSV is written to a real tmpfs
(/dev/shm), in the correct per-browser column layout, carrying the staged
strong passwords with the OLD ones absent, then securely shredded once the
human confirms — and the user's own export CSV is left untouched. The final
re-import into the browser remains a human step (no programmatic import API),
so the proof is scoped to staging, not end-to-end browser write.

No adapter code changed; only the validation-status DATA in §8.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/BROWSER-ROTATION.md

@@ -7,7 +7,8 @@ custody → **mandatory backup** → rotate/verify/commit → guide) — it is *
 
 Status: **Phase B (propagation engine) — built.** `pwgen` + `pwstore` (all five adapters) +
 the sealed staged-list + the `incredigo passwords scan|plan|guide|commit` surface are
-implemented and tested (keepassxc is LIVE-VM proven; the rest MOCK-ONLY — see §8). Phases
+implemented and tested (keepassxc + chrome/firefox staging are LIVE-VM proven; bitwarden /
+1password still MOCK-ONLY — see §8). Phases
 A-tier-1 / A-tier-2 (site automation) are specified here but **not yet built**. Nothing in this
 doc changes a password **at a website** automatically — the human still performs the site
 change + MFA; incredigo only propagates the new value into the *manager* afterward.
@@ -219,18 +220,31 @@ entries additionally record that a flag-gated plaintext file was created **and s
 ## 8. Validation status (DATA, mirrors `rotate/proofs.go` philosophy)
 
 The adapters contain ONLY real CLI/CSV code — no test branches. What differs is how each
-write path has been *validated*. Most adapters are still **MOCK-ONLY** (exercised against a
-fake `bw`/`op` binary or a fake export/import CSV); **keepassxc is LIVE-VM** — proven end to
-end (`scan → plan → commit → restore-from-backup`) against the genuine `keepassxc-cli 2.7.6`
-in the `incredigo-sbx` sandbox VM (`lab-provision-keepass.sh`).
+write path has been *validated*. **bitwarden / 1password** are still **MOCK-ONLY** (exercised
+against a fake `bw`/`op` binary). **keepassxc is LIVE-VM** — proven end to end
+(`scan → plan → commit → restore-from-backup`) against the genuine `keepassxc-cli 2.7.6`
+(`lab-provision-keepass.sh`). **chrome / firefox** are **LIVE-VM for the staging machinery**
+(real `/dev/shm` tmpfs + secure shred, correct per-browser layout) via
+`lab-provision-browsercsv.sh`; only the final human re-import is unproven (see note ²). All in
+the `incredigo-sbx` sandbox VM.
 
 | Adapter   | Write shape            | Secret path off-argv? | Validated against |
 |-----------|------------------------|-----------------------|-------------------|
 | bitwarden | `bw edit item` (stdin) | **yes** — base64 on stdin | fake `bw` (MOCK-ONLY) |
 | keepassxc | `keepassxc-cli edit -p`| **yes** — db+new pass on stdin | **real keepassxc-cli 2.7.6 (LIVE-VM)** |
 | 1password | `op item edit pw=…`    | **no** — argv assignment¹ | fake `op` (MOCK-ONLY) |
-| chrome    | tmpfs CSV → human re-import | n/a (no live secret to a child) | fake CSV (MOCK-ONLY) |
-| firefox   | tmpfs CSV → human re-import | n/a | fake CSV (MOCK-ONLY) |
+| chrome    | tmpfs CSV → human re-import | n/a (no live secret to a child) | **real /dev/shm + shred (LIVE-VM²)** |
+| firefox   | tmpfs CSV → human re-import | n/a | **real /dev/shm + shred (LIVE-VM²)** |
+
+² **chrome/firefox LIVE-VM scope:** there is no real browser to re-import into, so what is
+proven LIVE-VM (`lab-provision-browsercsv.sh` + `csv-commit-probe.py`) is the security-critical
+*staging* machinery that runs unattended: `commit --allow-csv` writes the new-password CSV to a
+real **tmpfs** (`/dev/shm`, confirmed `stat -f`), in the correct per-browser column layout
+(chrome `name,url,username,password,note`; firefox `url,username,password`), carrying the staged
+strong passwords with the OLD ones absent, and the file is **securely shredded** (unlinked) once
+the human confirms — while the user's own export CSV is left untouched. The final re-import into
+Chrome/Firefox itself is still a human step (no programmatic import API exists). The probe drives
+commit under a real pty so it pauses at the shred prompt long enough to inspect the file.
 
 **keepassxc LIVE-VM finding:** the CSV `Group` column is the FULL group path *including* the
 root group name (the default DB names its root `Passwords`), but `keepassxc-cli` addresses