## What happened

After locking the screen (Omarchy shell lock, dual-monitor setup), the displays do not stay dark. They blank via DPMS as expected ~5s after lock, but then spontaneously wake ~9s later showing the password prompt, blank again ~5s after that, and repeat this cycle indefinitely until the password is actually entered. No keyboard or mouse input occurred during the spontaneous wake events (confirmed via live log capture — see evidence below). The session remains securely locked throughout (`secure=true` never drops), so this is a display/DPMS bug, not a security issue.

## Expected behavior

Once DPMS turns the monitors off after locking, they should stay off until the user provides real input (keypress/mouse), not cycle on their own.

## Steps to reproduce

1. Have two monitors connected (in this case DP-1 + HDMI-A-1 on an AMD amdgpu setup).
2. Lock the screen (`omarchy system lock` or the normal lock keybind/menu action).
3. Don't touch the mouse or keyboard. Watch the monitors.
4. Observe: after the initial 5s blank, the screens wake on their own, briefly show the lock/password prompt, then blank again ~5s later. This repeats every ~15s.

## Evidence

I captured `hyprctl monitors -j` DPMS status on a 0.5s poll, and tailed the `omarchy-shell` journal (`journalctl -t omarchy-shell -f`), during a reproduction. Timeline:

```
23:32:39  lock-requested / secure=true
23:32:45  both monitors DPMS -> false (expected 5s post-lock blank)
23:32:54  both monitors DPMS -> true   <-- spontaneous wake, no input
23:33:00  both monitors DPMS -> false  (blank again, 5s later)
23:33:10  both monitors DPMS -> true   <-- spontaneous wake, no input
23:33:16  both monitors DPMS -> false  (blank again, 5s later)
23:33:24  real unlock (password typed) -> secure=false, unlocked
```

Each spontaneous wake at 23:32:54 and 23:33:10 lines up exactly with a burst of warnings in the shell log:

```
WARN scene: QML IpcHandler at .../plugins/agents/Panel.qml[327:3]: Handler was registered but will not be used because another handler is registered for target omarchy.agents
WARN scene: QML IpcHandler at .../plugins/panels/bluetooth/Panel.qml[640:3]: ... target omarchy.bluetooth
WARN scene: QML IpcHandler at .../plugins/panels/network/Panel.qml[210:3]: ... target omarchy.network
WARN scene: QML IpcHandler at @Ui/Panel.qml[48:3]: ... target omarchy.audio
WARN scene: QML IpcHandler at .../plugins/panels/monitor/Panel.qml[220:3]: ... target omarchy.monitor
WARN scene: QML IpcHandler at .../plugins/panels/power/Panel.qml[177:3]: ... target omarchy.power
WARN scene: QML IpcHandler at .../plugins/panels/weather/Panel.qml[476:3]: ... target omarchy.weather
WARN scene: QML IpcHandler at .../plugins/bar/widgets/SystemUpdate.qml[27:3]: ... target omarchy.system-update
WARN scene: QML IpcHandler at .../plugins/panels/clock/BarWidget.qml[129:3]: ... target omarchy.clock
WARN scene: QML IpcHandler at .../plugins/bar/widgets/Indicators.qml[168:3]: ... target omarchy.indicators
```

...appearing twice, ~2s apart, right at each wake. This indicates the shell's per-monitor panel components are being torn down and rebuilt at that moment. I checked whether this rebuild pattern happens continuously regardless of lock state by polling for 30s while unlocked/idle — it did not occur at all outside of the locked session, so it's specific to being locked.

## Suspected cause

`shell/plugins/lock/LockView.qml` wires a full-screen `MouseArea` so that `onPositionChanged` (and `onClicked`, `Keys.onPressed`) call `wakeRequested()`, which re-enables DPMS and re-arms the 5s blank timer (`shell/plugins/lock/Service.qml`, `idleBlankTimer` / `runBlank()` / `armBlankTimer()`). If the periodic per-monitor panel rebuild reflows/recreates the lock surface, that recreation appears to fire a spurious `positionChanged` on the MouseArea even though no real pointer motion occurred, which re-triggers `wakeRequested()` → DPMS enable → re-arm blank timer → repeat. What triggers the underlying ~14-16s panel rebuild while locked is unclear from the logs alone; it may be related to `wl_output` re-announcement around DPMS transitions causing Quickshell's per-screen `Variants` to rebuild.

## Environment

- Omarchy: 4.0.2-1
- Hyprland: 0.56.2
- Kernel: 7.1.9-arch1-2
- GPU: AMD Radeon RX 6700/6700XT (Navi 22, amdgpu driver)
- CPU: AMD Ryzen 5 7600X
- Displays: 2x BenQ GC2870 1920x1080@60, connected via DP-1 and HDMI-A-1
- Display server: Wayland (Hyprland), Xwayland 24.1.13

Full `omarchy debug --no-sudo --print` output available locally at `/tmp/omarchy-debug.log`; happy to attach/paste more of it on request.

---
Diagnosed with the help of Claude Code (log correlation via a live `hyprctl`/journal capture during reproduction).