docs(agent): #138 root-caused — our own reprobe restarts the graph under Chromium

Bernardo's hypothesis (pipewire restarts, Chromium never reconnects) is
right, and the journal names the restarter: dock-audio.nix:153 runs
`systemctl --user restart pipewire pipewire-pulse wireplumber` on every
monitoradded (#100). Chromium's audio service does not reconnect, so it
enumerates nothing — Meet's "no mic or speakers".

Ordering across four boots is decisive, and Bernardo asked for exactly
this check: restart-after-Chromium in both broken sessions (boot -3
14:06:49 → 14:07:52; boot -2 11:10:34 → 11:31:22), restart-BEFORE in
today's working one (08:04:19 vs 08:03:55, a 24s miss). Hibernate is not
the cause, only how a Chromium lives long enough to meet a plug event.

Retiers off [human] — no repro needed, and it predicts a live one:
dock/undock now should break Meet in this session. Fix is ours, not
Chromium's: the graph restart is inherited from "the old working flake",
never shown necessary, and repair_dock_cards already handles the parked-
card case without it.

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

agent/BACKLOG.md

@@ -211,29 +211,56 @@ scaled splash — the LUKS prompt especially, since a passphrase box half off
 the panel is the failure that matters. Pass = docked boot + shutdown centred
 on both heads; undocked unchanged.
 
-### 138. `[human]` Google Meet reports no mic or speakers; Zoom is fine
+### 138. Our dock-audio reprobe restarts PipeWire under running apps (Chromium loses its devices)
 
-Bernardo 2026-07-16 (T14s, docked): Meet insists there is no microphone or
-speaker even with the browser permission granted; Zoom calls work. What I
-could rule out from the live session, so the fix pass does not re-tread it:
+Bernardo 2026-07-16, refined by his own hypothesis (pipewire restarts →
+Chromium never reconnects) — which the journal confirms, and names **our own
+code as the thing doing the restarting**. Symptom: Google Meet reports no mic
+or speakers in native Chromium; Zoom is unaffected; it did **not** reproduce on
+a fresh boot, only after days of uptime + a hibernate.
 
-- The audio graph is healthy — PipeWire 1.6.5 with 4 sinks and 5 sources
-  (`wpctl status`), and a live `Chromium input` client was already attached.
-- Not a Flatpak sandbox: Chromium is the **native** nixpkgs build from the
-  template's `home.packages`. (Zoom, the app that works, is the Flatpak.
-  Brave — also Flatpak — holds `pulseaudio` + `xdg-run/pipewire-0` +
-  `devices=all`, so it would not fail this way either.)
-- One oddity worth checking first: the default source is **`OBSBOT Meet SE
-  Digital Stereo (IEC958)`** — an S/PDIF *passthrough* profile on the webcam,
-  a strange default for a mic. A device that enumerates but cannot open is a
-  plausible route to Meet's "no devices" wording.
+**Mechanism.** `modules/home/dock-audio.nix:153` — on every `monitoradded`, the
+`reprobe` path runs `systemctl --user restart pipewire.service
+pipewire-pulse.service wireplumber.service`. A full graph restart, on every
+physical monitor plug (#100). Chromium's audio service does not re-establish
+its PulseAudio connection when the server disappears under it, so it keeps
+running with a dead one and enumerates nothing — hence Meet's wording, hence
+"restarting Chromium fixes it". Zoom survives because it is a Flatpak that
+reconnects, and because it is generally started fresh into an already-restarted
+graph. **Hibernate is not the cause** — it is only how a Chromium survives long
+enough to still be running when a plug event arrives; resume-while-docked then
+generates the `monitoradded` that fires the reprobe.
 
-`[human]` because it needs the failure in front of us: **which browser** were
-you in (native Chromium, or the Brave Flatpak?), and with it open on Meet,
-`chrome://media-internals` plus the device list under `chrome://settings/content/microphone`
-would separate "Chromium enumerates nothing" from "Meet rejects what it is
-offered". Until then there is no way to tell a Nomarchy defect from a
-device-profile accident, and guessing costs more than asking.
+**Evidence — ordering is the whole tell** (`Started app-org.chromium.Chromium-*.scope`
+vs `reprobe-start`, four boots, no exceptions):
+
+| Session | Chromium | Graph restart | Order | Meet |
+|---|---|---|---|---|
+| boot -3 (Jul 14→15) | 14:06:49 | 14:07:52 (+2 more; then 10:52 next day) | **after** | broken |
+| boot -2 (Jul 15 daytime) | 11:10:34 | 11:31:22 | **after**, +21 min | broken |
+| boot 0 (Jul 16, fresh) | 08:04:19 | 08:03:55 | **before**, −24 s | works |
+
+Today is the negative control, and it is luck, not a fix: the restart missed
+Chromium by 24 seconds. **Prediction that confirms this outright — dock/undock
+now, then reload Meet: it should break in the current session**, with no reboot
+and no hibernate. That is the cheap V3 for the diagnosis, and it is also the
+regression test.
+
+**What to fix.** Not Chromium — the graph restart is a sledgehammer we
+inherited: the header comment justifies it only as "the recovery used by the
+old working flake", i.e. it was never shown to be *needed*, while its collateral
+(every long-lived audio client dropped) was never priced. It is also not rare —
+boot -3 took three restarts in 82 seconds (14:07:52 / 14:08:58 / 14:09:09;
+the `mkdir` debounce only collapses events within one run, not a plug storm),
+and each one drops audio for every app on the machine. Shape: **try selection
+first, restart only if nothing routable appears** — `select_first_dock` already
+falls back to `repair_dock_cards`, which fixes the parked-card case
+(`set-card-profile`) *without* touching the graph, so the restart may have no
+remaining job at all. If some HDMI codec really does need it (the other claim
+in that comment), prove it on this hardware and scope the restart to that case.
+Pass = plug/unplug the dock with Chromium open → output still follows to the
+monitor **and** Meet still sees its devices; `journalctl -t nomarchy-dock-audio`
+shows no graph restart on the ordinary path.
 
 ### 139. Terminal floats open full-screen — % size rules are ignored, and Kitty remembers