docs: RETRACT the #127 cause — the diagnosis was a measurement artifact; fix stands

The "blank + hypridle deadlock = the brick" cause published this morning is
retracted everywhere it was asserted: ROADMAP, hyprland.nix's comment, #146,
HARDWARE-QUEUE and two commit messages (a2151f4, 321ccf7). It rested on two
pieces of evidence and both were artifacts of how I measured:

- "19 disconnects in 11 days": 18 of 19 are hypridle's noisy goodbye while
  systemd DELIBERATELY stops it — each bracketed by `Stopped hypridle` /
  `Started hypridle`, healthy replacement seconds later.
- "Jul 14: CRITICAL at 13:08:17, then eleven hours of silence": an artifact of
  grepping ONE PID. systemd logged `Stopped hypridle` 13:08:17 and `Started
  hypridle` 13:09:00; PID 1678 ran fine all evening, invisible to the filter.

Decisive: at the incident (before the 12:51:34 mitigation commit) hypridle had
NO disconnect at all and had been healthy since Jul 14 13:09. It should have
fired on-resume normally. The deadlock theory never had a case.

The FIX stands on its own evidence and is untouched: the options really were
off, hypridle's on-resume really was the only caller of `dpms on`, and input now
wakes the screen with hypridle deliberately stopped (4s docked / 6s clamshell).
Removing a proven single point of failure never needed a story about why the
daemon might fail — which is exactly why it survived the story being wrong.

#127 is RESTORED to NOW (deleted this morning as "shipped"; only the fix
shipped). Its cause is open and the lead is the dead Ctrl+Alt+F3 — neither
DPMS-off nor a dead hypridle can break VT switching, so something was wedged
below the compositor holding DRM master. Every theory so far has been about the
wake path, i.e. a symptom of the screen already being black.

#146 → [watch], near-dead: one genuine zombie ever (verified by ps/ss, not
grep); upstream #171 is real but its impact path closed when #147's stray linger
went. Re-measure properly before building anything; close unbuilt if zero.

Also closes the #127 hardware-queue entry: Bernardo ran the real 10-min idle —
19:27:58 dpms off (genuine timeout, shipped config, and it BLANKED = the revert
working) -> mouse -> 19:32:14 `done enabled=1 first=DP-2`, clamshell, the
incident geometry, one healthy hypridle throughout. All 4 steps pass.

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

modules/home/hyprland.nix

@@ -1098,17 +1098,23 @@ in
         # reads as a glitch (item 28c, seen in the capture harness).
         background_color = rgb c.base;
 
-        # #127, and the whole answer to it. Hyprland ships both of these
-        # OFF, so nothing in the compositor turned a blanked screen back
-        # on: hypridle's on-resume was the ONLY caller of `dpms on` in the
-        # session — an idle daemon as a single point of failure with the
-        # display behind it. hypridle then deadlocks on an unfixed upstream
-        # bug (hyprwm/hypridle#171: "Disconnected from pollfd id 1", open,
-        # not in 0.1.7 or main) and hangs WITHOUT exiting, so Restart=always
-        # never fires and systemd still reports it active. Blank + deadlock
-        # = a black seat no keypress could escape. That was the brick.
-        # These put the wake in the compositor, where no daemon can lose it;
-        # a dead hypridle now costs auto-lock, not the machine.
+        # #127. Hyprland ships both of these OFF, so nothing in the
+        # compositor turned a blanked screen back on: hypridle's on-resume
+        # was the ONLY caller of `dpms on` anywhere in the session — an idle
+        # daemon as a single point of failure with the display behind it.
+        # Both facts verified on hardware 2026-07-16, as is the cure: with
+        # hypridle deliberately stopped and the screen blanked (i.e. the
+        # brick condition manufactured on purpose), a keypress woke it in 4s
+        # docked / 6s clamshell. The wake now lives in the compositor where
+        # no daemon can lose it; a dead hypridle costs auto-lock, not the seat.
+        #
+        # Deliberately NOT claimed: that this is what caused the original
+        # brick. An earlier version of this comment said so, citing a hypridle
+        # deadlock (hyprwm/hypridle#171) — that was wrong and is retracted:
+        # hypridle had no disconnect at all around the incident. Removing a
+        # proven single point of failure needs no such story. The cause is
+        # still open (BACKLOG #127); the dead Ctrl+Alt+F3 is its lead symptom,
+        # and neither DPMS-off nor a dead hypridle can produce that.
         key_press_enables_dpms = lib.mkDefault true;
         mouse_move_enables_dpms = lib.mkDefault true;
       };