fix(display): #148 — enforce dock intent without the auto-profiles toggle

Every nomarchy-home re-lit eDP-1 inside the shut lid: HM activation fires
hyprctl reload, the catch-all monitor rule re-enables the panel, and the
tick invariant built for exactly this (#142, enforce_dock_intent) never
fired — it was gated on settings.displayProfileAuto, the *named-profile*
auto-switch toggle, which is unrelated to dock intent and off unless
opted into. Confirmed live on the incident machine: dockMode=true,
displayProfileAuto unset, watcher journal empty — every tick returned at
that guard.

Fix: drop the auto_on gate. settings.display.dockMode alone is the
user's recorded intent (written by the menu and the dock transition);
the profile-active check remains as the real guard (a named profile
outranks the dock heuristic). No fight with the #142 undock hammer:
undock clears the intent before its rescue reload, so the enforcer
stands down by ordering.

tools/monitor-fallback.nix grows the reload-mid-dock scenario: fake lid
closed, hyprctl reload, panel re-disabled within ~4s, action=re-dock
logged — under displayProfileAuto's default false, i.e. the exact
condition the bug shipped under.

Verification: V2 — nix flake check --no-build green, checks.docking-ux
green, monitor-fallback harness green three times (implementer twice,
reviewer once, ~71s VM). V3 pending: relogin + nomarchy-home while
docked-clamshell (HARDWARE-QUEUE; the watcher is exec-once, the fix
arms at next login). Implementation by a Sonnet subagent; diagnosis,
design and review on Fable.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

agent/BACKLOG.md

@@ -197,36 +197,6 @@ 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. `[watch]` hypridle hangs instead of exiting when its compositor vanishes
 
 **Rewritten 2026-07-16, hours after filing: the premise was disproven and almost