test(display): de-flake the dock harness re-dock assertion (#154)

tools/monitor-fallback.nix flaked at the #148 reload-mid-dock step: after
a lid-closed `hyprctl reload` re-lights the disabled Virtual-1 panel, the
watcher's enforce_dock_intent re-disables it — but only on the loop's 1s
idle tick, because re-enabling an existing connector emits no
`monitoradded` and the chatty IPC events `continue` past reconcile. Under
this softGL VM's load (swaync crash-loops against the absent Vulkan
device) that idle tick is starved, so the re-dock lands ~15-20s out —
right on the old timeout=15.

An instrumented run confirmed the mechanism is correct: dockMode=true is
read, `action=re-dock` fires, the panel is re-disabled (it just missed the
bound). Fix is the bound, not the watcher: 15s → 45s, in line with the
test's own 20-30s waits. Harness now green end-to-end (~61s).

Not a product bug and independent of the #150 extraction (the built
transition/keyboard tools have byte-identical store paths across it).

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

docs/ROADMAP.md

@@ -541,11 +541,25 @@ Design/decision records and a running log of shipped work (items marked
   `nomarchy-display-transition` / `nomarchy-keyboard-layout` on HEAD vs the
   refactor. Gates: parse + home/toplevel builds + `checks.docking-ux`
   (structural, `bash -n` + safety-feature greps) all green. The
-  `tools/monitor-fallback.nix` dock VM harness is **red on `main` already**
-  (the #148 reload-mid-dock assertion — identical failure on clean HEAD;
-  BACKLOG #154), so it could not gate this; the dock transition inside it
-  still ran `result=ok`. The idle wake-path behaviour change (full undock,
-  incl. dock-intent clearing + `restore_keyboards`) is V3 — HARDWARE-QUEUE.
+  `tools/monitor-fallback.nix` dock VM harness was **red on `main` at the
+  time** — a flaky 15s bound on the #148 re-dock (identical failure on clean
+  HEAD), diagnosed and fixed the same day (see below), so it did not gate this
+  landing; the dock transition inside it always ran `result=ok`. The idle
+  wake-path behaviour change (full undock, incl. dock-intent clearing +
+  `restore_keyboards`) is V3 — HARDWARE-QUEUE.
+- ✓ **Dock harness de-flaked (#154, 2026-07-20):** `tools/monitor-fallback.nix`
+  flaked at the #148 reload-mid-dock assertion — after a lid-closed
+  `hyprctl reload` re-lights the disabled `Virtual-1` panel, the watcher's
+  `enforce_dock_intent` re-disables it, but only on the loop's 1s **idle
+  tick** (a reload re-enables an existing connector, emitting no
+  `monitoradded`, and chatty IPC events `continue` past `reconcile`). Under
+  the softGL VM's load — swaync crash-loops against the absent Vulkan device —
+  that idle tick is starved and the (correct, prompt-on-hardware) re-dock
+  lands ~15-20s out, right on the old `timeout=15`. Instrumented run proved
+  the mechanism fires with `dock-intent=true` and re-disables the panel; fix
+  is the bound (15→45s, matching the test's other 20-30s waits), not the
+  watcher. Harness now green end-to-end (61s). Not a product bug and unrelated
+  to #150 (byte-identical tool store paths).
 - ✓ **The idle brick's CAUSE found (#127 closed, 2026-07-17):** the incident
   was misdated — it did not happen "before 12:51:34 Jul 15" (that boot was
   healthy all day and ended in a routine clean reboot); it ended the