### System details

 - Omarchy: 4.0.2-1   - Hyprland: 0.56.2   - Quickshell: 0.3.1   - Kernel: 7.1.9-arch1-2   - CPU: AMD Ryzen 9 9900X   - GPU: AMD Radeon RX 7700 XT/7800 XT (discrete, Navi 32) + AMD Radeon Graphics   (Granite Ridge iGPU)

### What's wrong?

This is very annoying in a dark room. 
When my machine goes idle and the lock screen comes up, the display blanks out normally and stays locked the whole time (you still need the password to login back in), the screen keeps flashing on periodically. It shows the blurred background, with the password prompt, then goes dark again. 
### Steps to Recreate
- Let the machine sit idle past the lockout timeout so it locks and the display blanks out. 
- Do not touch. 
- Observe the screen will blink on briefly to show the lock screen, then it will blank again. 
- This will repeat until you hit the keyboard or mouse to wake it up. 


## Root cause (from Claude journal analysis)

Log source: `journalctl --user -u [email protected]`, filtered for `"omarchy idle"` / `"omarchy lock"` lines emitted by `plugins/services/idle/Service.qml` and `plugins/lock/Service.qml`.

Captured sequence (timestamps trimmed to the relevant window):

```
15:12:42.452  idle: lock-system: lock-timeout
15:12:42.452  idle: process-start: lock omarchy-system-lock
15:12:42.510  lock: lock-requested
15:12:42.510  lock: lock-pending: screen-stabilizing
15:12:42.549  idle: idle-monitor: idle                      <-- spurious re-idle, mid-lock
15:12:42.549  idle: idle-cycle-start: screensaver=150 lock=300
15:12:42.549  idle: process-start: screensaver [[ $(omarchy-shell lock isLocked) == "true" ]] || omarchy-launch-screensaver
15:12:42.553  idle: process-exit: lock exitCode=0 status=0
15:12:42.553  idle: idle-monitor: active
15:12:42.553  idle: idle-monitor-active: screensaver cycle remains armed
15:12:42.608  idle: process-exit: screensaver exitCode=0 status=0   <-- no-op: isLocked was true, so it never opened a screensaver window
15:12:43.024  lock: secure=true
15:12:45.551  idle: idle-cycle-cancel: screensaver-not-running       <-- grace timer misdiagnoses the no-op as a crash
15:12:45.551  idle: process-start: wake omarchy-system-wake          <-- defensively wakes the display
15:12:45.617  idle: process-exit: wake exitCode=0 status=0
15:15:12.554  idle: idle-monitor: idle                                <-- ~150s later, repeats
15:15:12.554  idle: idle-cycle-start: screensaver=150 lock=300
15:15:12.612  idle: process-exit: screensaver exitCode=0 status=0
15:17:42.554  idle: lock-system: lock-timeout
15:17:42.650  idle: process-exit: lock exitCode=0 status=0
```

Two things are happening together:

1. **The idle-notify signal itself flaps mid-lock.** Right as the lock is requested (`lock-requested` / `screen-stabilizing`), the idle monitor reports a fresh `"idle"` event (starting a brand-new idle cycle) and then almost immediately reports `"active"` again — with no real user input in between. This looks like Hyprland's `ext-idle-notify-v1` idle tracking reacting to the session-lock surface being created/mapped (seat/focus activity), not actual input.

2. **`screensaverLaunchGraceTimer` in `plugins/services/idle/Service.qml` doesn't know "already locked" is a valid reason for no screensaver window to appear.** The screensaver launcher (`omarchy-launch-screensaver`) correctly no-ops when `omarchy-shell lock isLocked` is `true` — it's not supposed to run over a lock screen. But the grace timer (`screensaverLaunchGraceTimer`, `plugins/services/idle/Service.qml`) only checks `screensaverWindowCount === 0 && !idleMonitor.isIdle`; it has no check for "are we already locked," so 3 seconds later it concludes the screensaver process crashed and calls `cancelIdleCycle("screensaver-not-running")`, which unconditionally runs `omarchy-system-wake` — turning the display back on and flashing the still-active lock surface into view.

The fix is presumably to have `screensaverLaunchGraceTimer`'s failure check also consult the lock service's `locked` state (available in-process via `shell.serviceFor("omarchy.lock").locked`, since `Service.qml` already receives `shell` as an injected property) and skip the false-positive wake when the system is already locked.