docs: #127 CLOSED — the brick was hypridle eating its own resume path

The incident was misdated: it did not happen before 12:51:34 Jul 15
(that boot was healthy all day) — it ended the previous boot at 10:54:22
with the power button. In that boot, running the pre-fix generation:
idle cascade on schedule (lock 10:21, dpms off 10:26, suspend correctly
skipped on AC), then hypridle logs "BUG THIS: inhibit locks < 0: -1" at
10:36:29 and its rule state is corrupted from there — the fired DPMS
listener's on-resume, then the session's ONLY dpms-on caller, never
dispatches again despite provable real input (two blind hyprlock PAM
attempts) and three output remove/re-add cycles. The wedged-compositor/
DRM-master lead is contradicted: Hyprland tracked hotplug live through
the whole window, PAM worked, kernel spotless. The shipped fix (a2151f4,
input wakes DPMS compositor-side) closes exactly this mechanism.

Filed upstream with the full trace: hyprwm/hypridle#208 (0.1.7; their
closed #104/#128 are the same class). Watch folded into #146.

Sweep: BACKLOG #127 deleted (NOW keeps only the install-findings context
stub, flagged to Bernardo); ROADMAP gains "The idle brick's CAUSE found"
and both stale "cause still open" tails patched; checked-off #127
HARDWARE-QUEUE blocks pruned, their method lessons moved to MEMORY
§ Gotchas.

Verification: V0 (docs/backlog only). The evidence is journal forensics
on the incident hardware (two Sonnet passes, verdict on Fable), quoted
in the ROADMAP entry; the fix itself was V3-proven 2026-07-16.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ROADMAP.md

@@ -493,6 +493,36 @@ Design/decision records and a running log of shipped work (items marked
   V2 by render, both heads + the password dialog, via the new
   `tools/plymouth-preview.sh`. V3 (a real docked boot/shutdown) is queued: the
   fake heads exist from the start, so the rig cannot resize a canvas.
+- ✓ **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
+  *previous* boot at **10:54:22** with the power button (unclean end:
+  journald corruption + FAT dirty bit on the next boot; final seconds: dock
+  unplug/replug storm 10:52:54–10:53:58, lid open 10:54:00). Every earlier
+  hypridle timeline was built against the wrong boot. **Proven** from that
+  boot's journal (running the pre-fix generation of 07-10): normal idle
+  cascade — 10:21 lock, 10:26 `dpms off`, 10:31 suspend correctly skipped
+  on AC — then at **10:36:29 hypridle logs `BUG THIS: inhibit locks < 0:
+  -1`** (inhibitor-count underflow, its own words), after which its rule
+  state is demonstrably corrupted: the 300s lock listener re-arms,
+  re-fires (10:41:29) and Resumes (10:43:49), but the fired DPMS
+  listener's `on-resume` — then the session's **only** `dpms on` caller —
+  never dispatches again, through provable real input (two blind hyprlock
+  PAM attempts, 10:44:21 and 10:52:40) and three output remove/re-add
+  cycles. **The wedged-compositor/DRM-master lead is dead:** Hyprland
+  tracked hotplug live through the whole window, PAM/fprintd worked, the
+  kernel is spotless (zero amdgpu/DRM/PSR errors). The dead Ctrl+Alt+F3
+  stops being load-bearing — no VT-switch trace exists at all (the
+  keystrokes plausibly never left the flapping dock, and nothing would
+  have re-lit the panels either way); it was only ever evidence *for* the
+  wedge, and the wedge is contradicted. **Inferred, not provable from
+  logs:** the underflow caused the corruption — the correlation is tight
+  and hypridle flagged the bug itself. Consequence: the shipped fix
+  (a2151f4, `key_press/mouse_move_enables_dpms`) closes exactly this
+  mechanism — the first blind keystroke would have re-lit the screen.
+  Upstream: hyprwm/hypridle#208 (filed 2026-07-17 with the full trace;
+  0.1.7, same class as their closed #104/#128). The watch rides in
+  BACKLOG #146.
 - ✓ **Post-install hardware hints (VISION § B, 2026-07-17):** after the #81
   "you're set" card, at most one additional "Hardware tips" toast — a
   Firmware line when `fwupdmgr` is on PATH, a Fingerprint line when
@@ -666,7 +696,9 @@ Design/decision records and a running log of shipped work (items marked
   is provably innocent). But "an ordinary blank + a recovery that could not run"
   is **not** established: the wake path had a real single point of failure, which
   is fixed, yet nothing shows it had failed *during the incident*. The brick's
-  cause is still open. See "#127's WAKE PATH fixed" below.
+  cause was still open at this writing — **found 2026-07-17** (and it *was*
+  the wake path failing during the incident, via hypridle state corruption):
+  see "The idle brick's CAUSE found" above.
 - ✓ **The #107 compat shim is pinned (#133, 2026-07-16):** `mkFlake` prefers
   `state.json` and still accepts the legacy `theme-state.json`, because a
   machine only migrates on its next menu write — but nothing evaluated a
@@ -827,7 +859,9 @@ Design/decision records and a running log of shipped work (items marked
   and a rate that counted normal shutdown noise. Both times the error was
   inferring where checking was available and cheap. Verify the instrument before
   believing the reading, *especially* when the reading confirms the theory.
-  **Still open — #127's cause, now the lead question (BACKLOG #127).** We know
+  **Was still open at this writing — resolved 2026-07-17, and the lead below
+  did not survive the boot -4 forensics (see "The idle brick's CAUSE found"
+  above).** We know
   the wake path had a single point of failure and we removed it; we do **not**
   know what actually bricked the machine. The **dead Ctrl+Alt+F3 is the strongest
   clue and points away from everything examined so far**: neither DPMS-off nor a