Wake the panel when a laptop-only lid opens

[codemonkey76]

Fixes the gap reported in #10170, whose analysis this follows.

The lid-open binding runs omarchy-hyprland-monitor-clamshell. That reconciler dispatches a DPMS enable only from enable_internal(), behind if (( changed )) — true only when a clamshell flag file was just removed. The flag is never written when there is no external monitor, so on a laptop-only machine the reconciler runs and dispatches nothing.

Meanwhile lock/Service.qml's idleBlankTimer blanks the panel five seconds after a lid-close lock. So a laptop-only lid resume returns to a dark screen with no path back. Only Keys.onPressed on the lock screen's password field reaches omarchy-system-wake, and logind swallows the power button (10-ignore-power-button.conf) — so the machine looks hung to anyone who reaches for the power button rather than typing.

The fix

Bind lid open to omarchy-system-lid-open, mirroring the existing omarchy-system-lid-close: reconcile first, exactly as before, then wake.

The wake had to stay a no-op when nothing is dark — omarchy-hyprland-monitor-internal's recover() warns that an unconditional wake "undoes lock-screen blanking and races the resume modeset into a visible flash", and the clamshell watcher polls the reconciler every few seconds. Two things keep that true here: the wake sits on a lid-switch event rather than in the polled reconciler, and omarchy-brightness-display on already exits early while every enabled monitor reports dpmsStatus true.

Test plan

• New test/shell.d/lid-open-test.sh asserts the handler reconciles first, then wakes, and does nothing else. Verified non-vacuous — dropping the wake line fails it with "second call was none".
• test/shell.d/monitor-recovery-test.sh updated for the new binding.
• ./test/all — the only failure is bin-style-test.sh, which fails identically on the base commit (raw command -v in the AI app removers, fixed separately in Use the command helper in the AI app removers #10460).
• Hardware A/B on a laptop-only machine (Intel CometLake-H + NVIDIA hybrid, eDP-1 only, deep S3), blanking the panel exactly as the lock screen does:

blanked (as after lid-close lock): [{"name":"eDP-1","dpmsStatus":false}]
after omarchy-system-lid-open   : [{"name":"eDP-1","dpmsStatus":true}]

blanked again                   : [{"name":"eDP-1","dpmsStatus":false}]
after monitor-clamshell alone   : [{"name":"eDP-1","dpmsStatus":false}]   <- current binding

Scope note: this machine hit a dark panel on an 11-hour lid-closed resume (lid closed 19:07:14, opened 06:32:06, no external monitor), which is what led here. The structural gap above is confirmed and fixed. I can't prove it was the only cause of that particular incident — one observation from it recorded dpmsStatus: 1 while the panel was dark, and I can't now reconstruct whether that reading was taken before or after a manual dpms enable. If a compositor-vs-hardware desync also exists on this hardware, it is a separate bug and this does not address it.

🤖 Generated with Claude Code

https://claude.ai/code/session_013p9Qh6dX4FuwBJAWhNPVbn