docs: correct a false claim in 321ccf7, and file #148 (reload re-lights a shut lid)

321ccf7 claimed the 4s step-4 run was "docked, lid OPEN" and that it retired
the old "docked lid-open is untested" caveat. Both wrong, per Bernardo: the
lid was SHUT throughout. eDP-1 was lit inside a closed clamshell because a
reload had re-enabled it, and "lid open" was inferred from an output being
enabled — which is not evidence of a lid position. /proc/acpi/button/lid/*/
state is, and it was never checked; it reads `closed` with eDP-1 enabled and
dpms_on=true right now. Docked-lid-open stays untested (moot — the gate is
gone — but untested). The step-4 result itself stands: input woke it in 4s
with hypridle stopped, with two outputs enabled rather than one.

That correction exposes a real bug, filed as #148: `hyprctl reload` re-enables
every output (the #142 hammer the undock rescue relies on), but
nomarchy-display-watch only reacts to monitoradded/monitorremoved — a reload
emits neither, so nothing re-asserts the dock profile. Every HM activation
reloads Hyprland, so every rebuild while docked-clamshell lights the panel and
leaves it lit. Bernardo hit it twice in ten minutes today: once from
nomarchy-home, once from an agent's reload that silently undid the fix he had
just made by hand in the Display menu.

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

agent/BACKLOG.md

@@ -136,6 +136,35 @@ high-ROI, etc.) live in the journal + ROADMAP — not here.*
 
 ### Product / day-2
 
+### 148. Every `nomarchy-home` re-lights the laptop panel inside a shut lid
+
+Bernardo, 2026-07-16, and he hit it twice in ten minutes: after `nomarchy-home`
+the laptop panel "turns on again" while docked **lid closed**, and he had to
+re-set docking by hand from the Display menu. Then an agent's `hyprctl reload`
+silently undid his fix and re-lit it a second time — confirmed live:
+`/proc/acpi/button/lid/*/state` = `closed` with `eDP-1` enabled and
+`dpms_on=true`, i.e. a panel burning inside a shut clamshell with nobody
+looking at it.
+
+**Cause is a known hammer with no follow-through.** `hyprctl reload` re-applies
+every monitor rule and re-enables every output — the ROADMAP already calls this
+"the #142 hammer", and the undock transition *relies* on it. But
+`nomarchy-display-watch` only reacts to `monitoradded`/`monitorremoved`; a
+reload emits neither, so nothing re-asserts the dock profile and the panel just
+stays on. Any HM activation reloads Hyprland, so **every rebuild while
+docked-clamshell lights the panel** and leaves it lit until the user notices.
+Journal for the window is empty — display-watch never saw a thing.
+
+Cost: wasted power and panel life, and the live display state silently diverging
+from the profile the user chose — the exact class of "you have to fix it by
+hand" that the display work exists to remove. Fix is probably to re-assert the
+dock/clamshell profile *after* a reload rather than only on hotplug: either
+watch the lid switch as a trigger in its own right (logind already knows), or
+have the transition/activation path re-run the dock decision once the reload
+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