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>

agent/BACKLOG.md

@@ -31,44 +31,6 @@ post-boot sessions). Preserve separation: the installer bake failure and the
 flake pin are different root causes even when they show up on the same machine.
 (Terminal / Ghostty-on-Acer → shipped as Kitty-only, #95.)
 
-### 127. `[blocked:hw]` The idle brick's CAUSE — reopened; the fix shipped, the diagnosis did not
-
-**Restored 2026-07-16, same day it was deleted.** It was deleted as shipped on
-the strength of a diagnosis that was retracted hours later. The **fix** is real,
-proven and stays (`misc:{key_press,mouse_move}_enables_dpms`, a2151f4): the wake
-path had a genuine single point of failure — hypridle's `on-resume` was the only
-caller of `dpms on` in the session — and it is gone. Verified end-to-end on the
-incident hardware, including a real 10-min idle blanking and waking clamshell
-(`done enabled=1 first=DP-2`, 19:32). **None of that explains the brick.**
-
-**What the incident was:** docked clamshell, idle → black, external keyboard and
-mouse woke nothing, unplugging the external did not light the panel, Caps Lock
-LED still toggled (machine alive), and **Ctrl+Alt+F3 gave no usable TTY**.
-
-**What has been ruled OUT (all on hardware, 2026-07-16):**
-- *DPMS-off is not the trigger.* With hypridle driving the blank, input wakes it
-  in every geometry — undocked lid-open, clamshell-docked on the sole live
-  output, docked with both outputs live. The clamshell skip was reverted on this.
-- *The hypridle deadlock is not the trigger.* This was the published cause and it
-  was wrong: at the incident (before 12:51:34 on Jul 15) hypridle had **no
-  disconnect at all** and had been healthy since Jul 14 13:09. The "19 in 11
-  days" rate that made the theory look strong was normal-teardown noise
-  (see #146). It should have fired `on-resume`.
-- *The #100 undock latch* explains symptom 2 (unplugging not restoring the panel)
-  and is fixed (ff5017e) — but not the blackout itself.
-
-**The lead is Ctrl+Alt+F3, and it always was.** Neither DPMS-off nor a dead
-hypridle can break VT switching; a wedged compositor still holding DRM master
-can, and it would explain the black screen *and* the dead TTY in one stroke.
-Every theory so far has been about the wake path — i.e. about a *symptom of the
-screen being black* — and none of them touch the TTY. Start there instead.
-Bernardo does not recall whether the machine had been relogged-in between Jul 14
-13:09 and the incident; that would say whether hypridle was ever a suspect.
-
-**Note the fix makes this much harder to reproduce** (input now wakes the screen
-compositor-side), which is a good trade but means a repro may need the options
-temporarily off. It has not recurred since.
-
 ## NEXT
 
 ### 143. Rofi keeps the selected *row number* when the search changes, so the highlight lands on an unrelated entry
@@ -219,6 +181,17 @@ is upstream hyprwm/hypridle#171 ("Possible deadlock in pollThr when compositor
 exits?", open since 2025-09, in neither 0.1.7 nor main) and it is a true bug:
 hypridle hangs rather than exits, so `Restart=always` never fires.
 
+**A second real one joined it with #127's close (2026-07-17):** an
+inhibit-lock underflow (`BUG THIS: inhibit locks < 0: -1`, hypridle's own
+words, Jul 15 10:36:29) left the fired DPMS listener's `on-resume` permanently
+dead on 0.1.7 — the incident's actual mechanism (ROADMAP § "The idle brick's
+CAUSE found"). Reported upstream with the full trace 2026-07-17:
+https://github.com/hyprwm/hypridle/issues/208
+(#74/#104/#128 are the same class, closed before 0.1.7 evidently without
+killing it). Its impact path here is closed by the compositor-side wake fix
+(a2151f4); same watch posture — take the upstream fix when a release carries
+it.
+
 **But its impact path is closed, which is why this is `[watch]` and not work.**
 The zombie only *persists* if systemd never stops the unit — which needed the
 user manager to survive logout, i.e. the stray pre-migration linger removed in