docs: log Chrome SIGBUS incident from Btrfs csum corruption

Chrome crashed repeatedly with SIGBUS on launch. Root cause was a
corrupt data block in ~/.config/google-chrome/Profile 2/Favicons on a
single-copy Btrfs volume (csum failures correlated to the second with
each crash). A scrub found two further uncorrectable blocks (a Chrome
cache file and a gdm help file); both fixed. SSD SMART is clean and the
corruption is static across scrubs, pointing at a past RAM/bus event
rather than a failing drive.

Adds docs/incidents.md (dated incident log) and a CLAUDE.md pointer.

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

CLAUDE.md

@@ -37,6 +37,7 @@ Do NOT use `^(...)$` wrapping — Hyprland 0.51 rejects it as "Invalid rulev2".
 - `docs/hyprland/` — version-aware Hyprland config reference; update these when Hyprland is upgraded
 - `docs/synology.md` — DS218plus SSH alias, `/volume1/backup` map, restic repo commands, recovery notes
 - `docs/vps-inventory.md` — OVH VPS (`ovh-vps`) access notes; old Hyperthrive DO VPS deleted 2026-06-24 (historical notes retained)
+- `docs/incidents.md` — dated incident log (diagnosed-and-fixed issues): symptom, root cause, ruled-out, fix, follow-up
 
 ## Project status
 

docs/incidents.md

@@ -0,0 +1,96 @@
+# Incident log
+
+Dated entries for diagnosed-and-fixed system incidents on this machine.
+Newest first. Keep entries factual: symptom, root cause, what was ruled out,
+fix applied, and any follow-up.
+
+## 2026-06-24 — Chrome repeatedly crashing (SIGBUS), corrupt Favicons block on single-copy Btrfs
+
+**Symptom**
+
+Google Chrome crashed within seconds of launch, repeatedly. Three crashes in
+three minutes on 2026-06-24 (13:15, 13:16, 13:17), all signal **SIGBUS**.
+History of crashes back to April (mixed SIGTRAP / SIGILL / SIGSEGV / SIGBUS),
+18 minidumps total.
+
+**Root cause**
+
+A single corrupt data block at offset **942080** of
+`~/.config/google-chrome/Profile 2/Favicons` (a SQLite DB, inode 141150,
+btrfs root 257). Chrome `mmap()`s the file on startup; the kernel raises SIGBUS
+when it cannot fault in the bad page.
+
+Each SIGBUS coredump correlated to the second with a kernel log line:
+
+```
+BTRFS warning: csum failed root 257 ino 141150 off 942080 csum 0x0858109c expected 0x0858109e mirror 1
+```
+
+Same single-bit flip every time (`9c` vs `9e`). The volume is `Data, single`
+(no mirror), so Btrfs detects but **cannot self-heal**. `corruption_errs` was
+climbing (41 → 42). Disk `read` / `write` / `flush` `io_errs` were all 0 —
+silent at-rest corruption; the NVMe is not reporting hardware faults.
+
+**Ruled out**
+
+- **OOM** — 87 GiB RAM free, and SIGBUS ≠ SIGKILL.
+- **Disk full** — 5% used.
+- **Chrome version / update** — install dated 2026-06-20 predates the crashes;
+  `rpm -V` clean.
+- **Profile / extension corruption.**
+- **Dual-GPU / Wayland stack** — GPU libs in the dump were merely mapped; the
+  `gpu_channel.cc Buffer Handle is null` line was a downstream symptom logged
+  ~2s after the SIGBUS.
+
+**Fix applied (2026-06-24)**
+
+Confirmed Chrome not running, then deleted the regenerable cache files
+`Favicons` and `Favicons-journal` from `Profile 2/`. Chrome regenerates these on
+next launch. Verified gone.
+
+**Scrub result (2026-06-24 13:28)**
+
+`sudo btrfs scrub start -B /home` finished in 0:55, scanned 79.57 GiB.
+**Error summary: `csum=2`, Corrected 0, Uncorrectable 2.** The corruption is
+**not** isolated to the Favicons file — two further uncorrectable blocks, in
+two different subvolumes, both regenerable/reinstallable:
+
+| File | Subvol | Action |
+|------|--------|--------|
+| `~/.cache/google-chrome/Profile 1/Cache/Cache_Data/5f188fe6012a3cdc_0` | home (root 257) | Deleted (regenerates) ✅ |
+| `/usr/share/help/fr/gdm/index.docbook` | root (root 259) | Owned by `gdm-49.2-2.fc43`; restore via `sudo dnf reinstall gdm` |
+
+`corruption_errs` 44; `read`/`write`/`flush` `io_errs` 0.
+
+**Remediation + verification (2026-06-24 13:38–13:42)**
+
+- Deleted the Chrome cache block (`rm`, regenerates).
+- Restored the gdm file: `sudo dnf reinstall gdm`.
+- **SSD health is clean** — `sudo nvme smart-log /dev/nvme0n1`:
+  `critical_warning 0`, `media_errors 0`, `percentage_used 0%`. The drive has
+  logged **zero** media errors at the hardware level → a *failing SSD* is
+  unlikely; corruption reached good flash from upstream (RAM/bus).
+- **Second scrub (13:41)** still reports `csum=2` uncorrectable — but at the
+  **exact same two physical blocks** as the first scrub (`logical 1754923008`,
+  `logical 21439315968`), and this time **with no resolvable path**. The live
+  files now point at fresh extents; the corrupt extents are **orphaned dead
+  blocks** (not snapshot-pinned — `snapper`/`timeshift` not installed).
+
+**Assessment**
+
+Same two static blocks across two scrubs 13 min apart = corruption is **static,
+not actively spreading** (no new blocks appeared). Combined with the clean SSD
+SMART, this most likely stems from a **single past corruption event** rather
+than an actively-failing component. The crash-causing live files are fixed;
+the residual scrub errors affect no live file.
+
+**Outstanding / follow-up**
+
+- **Re-scrub in a day or two** (`sudo btrfs scrub start -B /home`). If the two
+  orphaned blocks have cleared (reclaimed) and no *new* errors appear → fully
+  resolved. **New** blocks appearing = corruption is ongoing → back up now and
+  run memtest.
+- **Run memtest86+** (Fedora GRUB boot entry) for confidence — scattered
+  multi-file corruption with zero drive I/O errors is the classic bad-RAM
+  signature, even if currently static.
+- The `corruption_errs` counter will not drop on a single-copy volume — expected.