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/HARDWARE-QUEUE.md

@@ -60,57 +60,6 @@ Everything else below stays open; order is convenience, not a gate.
       restores **only** the radios that were on before. If Wi-Fi was already
       off, it must stay off after disengage. Glyph must **not** appear when
       airplane is off.
-- [x] **#127 TESTS A + B — ANSWERED 2026-07-16 (AMD dev box), both closed.**
-      TEST B ran and DPMS-off is **not** the trigger: with hypridle driving the
-      blank, input woke it in all three configurations including clamshell-docked
-      on the sole live output. The mitigation was reverted and #135 retired
-      unbuilt, which also voids TEST A (its premise — the skip — no longer
-      exists). What that leaves: Hyprland's input→DPMS options ship off, so
-      hypridle's `on-resume` was the only caller of `dpms on` — a real single
-      point of failure, now removed. It is **not** known to be what bricked the
-      machine: the "hypridle deadlock" cause published on the day was retracted
-      the same day (hypridle had no disconnect at the incident). #127 is reopened
-      for its cause; ROADMAP § "#127's WAKE PATH fixed" is the full record.
-      **Method note worth keeping:**
-      the *first* TEST B was invalid — it ran `dpms off` by hand, which no wake
-      path watches, so its "input did not wake it" was guaranteed regardless of
-      hardware. Drive the real code path or measure nothing.
-- [x] **#127 fix from config — ALL 4 STEPS PASSED 2026-07-16 (AMD dev box)**
-      — a2151f4 applied via `nomarchy-pull` + `nomarchy-home` on the dev box.
-      **Done, no need to redo:**
-      1. ✓ Both options read `int: 1` after `hyprctl reload` (which discards
-         runtime keywords), so our Nix — not a keyword — supplies them.
-         `nomarchy-dpms-off` is gone from the closure and the live
-         `hypridle.conf` reads `on-timeout=hyprctl dispatch dpms off`.
-      4. ✓ The brick condition on purpose, from config: `systemctl --user stop
-         hypridle` + `hyprctl dispatch dpms off` → **keypress woke it in 4s**,
-         with both outputs enabled (`DP-2,eDP-1`). The clamshell variant (DP-2
-         alone) woke in 6s the same day. Wake proven with one enabled output
-         and with two; DPMS-on-input is compositor-level and does not care how
-         many.
-         **Correction (2026-07-16, Bernardo):** the commit that added this
-         entry (321ccf7) claimed that 4s run was "docked, lid OPEN" and that it
-         retired the old "docked lid-open is untested" caveat. **Both wrong.**
-         The lid was **shut the whole time** — `eDP-1` was lit *inside a closed
-         clamshell* because a `hyprctl reload` had re-enabled it (#148). "Lid
-         open" was inferred from an output being enabled, which is not evidence
-         of anything: `/proc/acpi/button/lid/*/state` is, and it was never
-         checked. Docked-lid-open remains **untested** — moot now that the gate
-         is gone, but not tested. Do not read output lists as lid positions.
-      2+3. ✓ **The real idle path, no scaffolding** (Bernardo, 19:22–19:32,
-         docked **lid closed**): `19:22:58 Executing pidof hyprlock || hyprlock`
-         (5 min) → `19:27:58 Executing hyprctl dispatch dpms off` — the genuine
-         10-min timeout firing from the shipped config, and it **blanked**, which
-         is the revert working → mouse move → `19:32:13 Resumed: … Executing
-         …/nomarchy-display-wake` → `19:32:14 done enabled=1 first=DP-2`.
-         `enabled=1 first=DP-2` = clamshell, the incident's exact geometry. One
-         healthy hypridle (PID 683145) throughout.
-      Note: step 1 used `hyprctl reload` rather than a full relogin — a reload
-      re-reads the same on-disk config a new session would, so the gap is
-      cosmetic, but a relogin has not literally been done.
-      **Entry closed. #127 itself is reopened for its CAUSE (see BACKLOG) —
-      the wake path is fixed and verified; what bricked the machine is not
-      known, and the dead Ctrl+Alt+F3 is the lead.**
 - [ ] **#96 battery-limit row on threshold-less firmware (Acer M5-481T)** —
       on the Acer (live or installed session with the commit carrying this
       entry): open System (`SUPER+CTRL+I`). **Pass:** a "Battery limit" row