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>

agent/BACKLOG.md

@@ -31,6 +31,44 @@ 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
@@ -165,48 +203,44 @@ settles. Note the ordering trap — the reload is also the undock rescue, so
 whatever re-asserts must not fight the rescue that deliberately re-enables eDP
 when the lid is open.
 
-### 146. hypridle dies silently and systemd calls it healthy
 
-Fell out of the #127 diagnosis (2026-07-16, ROADMAP § "#127 solved"), and it is
-the bug that was actually behind the brick — the DPMS gate we just reverted was
-only ever a symptom shield. hypridle hits an unfixed upstream deadlock
-(hyprwm/hypridle#171, "Disconnected from pollfd id 1" — open since 2025-09, in
-neither 0.1.7 nor main; upstream's own reporter saw 10-hour hangs) and then
-**hangs without exiting**, so `Restart=always` never fires and `systemctl
---user is-active` still says `active (running)`. On the dev box: **19 times in
-11 days**, including the incident day. Jul 14 is the clean example — locking
-normally at 13:02, `CRITICAL` at 13:08:17, then eleven hours of silence, with
-D-Bus receive queues visibly backing up (48 KB unread) because nothing was
-reading them. The compositor is *fine* through all of it (no other session unit
-dies in the same second), so this is not the compositor's death taking it down.
+### 146. `[watch]` hypridle hangs instead of exiting when its compositor vanishes
 
-Now that input wakes the screen compositor-side this is no longer brick-class,
-but it is not cosmetic either: a silently dead hypridle means **no auto-lock**
-(Bernardo sat unlocked for 25 min on 2026-07-16 without knowing), no blank, no
-idle suspend. Cost: systemd can't see it — `WatchdogSec` needs `sd_notify`
-hypridle doesn't implement, and the process never exits — so detection has to be
-external: a guard watching for the `CRITICAL` line, or a liveness probe on its
-Wayland fd, then `systemctl --user restart hypridle`.
+**Rewritten 2026-07-16, hours after filing: the premise was disproven and almost
+nothing survives.** As filed it said hypridle "dies silently ~2×/week — 19 times
+in 11 days", with Jul 14 as the clean example ("`CRITICAL` at 13:08:17, then
+eleven hours of silence"). Every number there was an artifact of the
+measurement. **18 of the 19** `Disconnected from pollfd id 1` lines are
+hypridle's noisy goodbye while systemd *deliberately stops it* — each bracketed
+by `Stopped hypridle` / `Started hypridle` with a healthy replacement seconds
+later. The "eleven hours of silence" came from grepping **one PID**: systemd
+logged `Stopped hypridle` 13:08:17, `Started hypridle` 13:09:00, and PID 1678
+ran fine all evening where the filter could not see it. Do not re-derive the old
+rate; it counts normal shutdown noise.
 
-**Correction 2026-07-16:** this entry originally said "sequence it after #147,
-because restarting hypridle into a dead compositor fail-loops into
-`start-limit-hit` exactly as cliphist does". **That reasoning is void** — #147
-turned out not to be a distro bug at all (it needed stray pre-migration linger,
-since removed), and cliphist's fail-loop was a symptom of that same stray state.
-There is no ordering constraint: **#146 stands on its own and can be taken
-first.** The underlying caution survives in weaker form and is still worth
-designing for — a guard must not restart hypridle into a session whose
-compositor is gone — but that is ordinary care in the guard, not a dependency
-on another item.
+**What is real, and it is small.** Exactly one genuine zombie has been observed
+(2026-07-16 17:25:39), verified by process inspection rather than logs — `ps`
+(alive 9h36m), `ss` (48 KB unread on its D-Bus socket, i.e. not reading),
+`NRestarts=0` while `systemctl --user is-active` said `active (running)`. That
+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.
 
-The trigger is still unknown — *not* dock/undock (no display-watch activity in
-the 3 min before any of them) and *not* a D-Bus quota disconnect (no broker
-errors). **Note the 19-in-11-days figure was measured on a box with linger on**;
-whether the rate holds now that the user manager is torn down at logout is
-itself unknown, and re-measuring is the cheap first step before building a guard.
-Worth a reproducer + an upstream comment on #171: it has sat ten months on
-vaxerski's "that will cause a segfault no?", and we have better data than the
-reporter did.
+**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
+#147. Without linger, logout tears the manager down and takes any zombie with
+it; the Jul 14 trace above shows the healthy path (`Stopped` → `Started`) doing
+exactly that. A Hyprland death ends the logind session anyway (2026-07-16:
+`Session 2 logged out` → greeter), so there is no known route left to a
+surviving zombie.
+
+**Do before building anything:** re-measure. Count only disconnects with **no**
+`Stopped/Started hypridle` around them and **no** logind session event, and
+confirm by `ps`/`ss` that the process is really wedged — not by grepping a PID.
+If that count is zero over a few weeks post-linger, **close this unbuilt**. If it
+is not, the upstream issue has sat ten months on vaxerski's "that will cause a
+segfault no?" and a reproducer would be worth more than a local guard.
 
 ### 147. Nomarchy cannot see machine state it never set — and it bit the QA box for 6 months