### System details
- **Hardware**: Framework Desktop, AMD Ryzen AI Max 395 (Radeon 8060S Graphics)
- **Omarchy Version**: 4.0.0-1 (Quattro)
- **Hyprland Configuration**: Lua parser (`~/.config/hypr/hyprland.lua`)
- **Display Setup**: 3 monitors (`DP-1` portrait, `HDMI-A-1` ultrawide, `DP-4` landscape) vs 2 monitors tested
- **Terminal**: Kitty

### What's wrong?
On multi-monitor setups with 3 or more displays, `omarchy-launch-screensaver` triggers and then immediately self-terminates after a few seconds without any user interaction. On a 2-monitor system with identical Omarchy Quattro configuration, the screensaver runs as expected.

When the screensavers self-terminate, `omarchy-shell`'s idle manager (`Service.qml`) interprets the closed windows as a manual dismissal, issues `omarchy-system-wake`, and cancels the idle sequence—preventing `idle.lock` (300s) and display DPMS power-down from ever activating.

### Mechanism & Root Cause

1. **Sequential Output Launch Loop**:
   In `/usr/bin/omarchy-launch-screensaver`, screensavers are spawned sequentially across all connected displays:
   ```bash
   for m in $(hyprctl monitors -j | jq -r '.[].name'); do
     hypr_focus_monitor "$m"
     case $terminal in ... esac
     wait_for_screensaver_window
   done
   hypr_focus_monitor "$focused"
   ```
   Each monitor iteration focuses the monitor, spawns the terminal screensaver window, and waits for the corresponding socket2 `openwindow` event.

2. **The 3+ Monitor Timing Race**:
   In `/usr/bin/omarchy-screensaver`, the main loop starts checking focus immediately with a 1-second timeout:
   ```bash
   while pgrep -t "${tty#/dev/}" -x ttfx >/dev/null; do
     if read -n1 -t 1 || ! screensaver_in_focus; then
       exit_screensaver
     fi
   done
   ```
   - On a **2-monitor system**, the loop completes quickly enough that both windows map and focus is restored to the primary monitor within ~1 second.
   - On a **3+ monitor system**, cycling through all three displays takes 2–4 seconds.
   - While the launcher is busy focusing Monitor 2 and Monitor 3, Monitor 1's screensaver process reaches its first 1-second timeout and evaluates `screensaver_in_focus`.

3. **Global Active Window Query**:
   `screensaver_in_focus()` checks global compositor focus:
   ```bash
   screensaver_in_focus() {
     hyprctl activewindow -j | jq -e '.class == "org.omarchy.screensaver"' >/dev/null 2>&1
   }
   ```
   Because compositor focus is actively transitioning to Monitor 2/3 (or momentarily lands on existing windows on those workspaces before the screensaver terminal is mapped), Monitor 1 sees that `activewindow` is not its own screensaver class. `! screensaver_in_focus` evaluates to true, executing `exit_screensaver` (`pkill -f org.omarchy.screensaver`) and killing all screensavers across all monitors.

### Steps to Reproduce
1. Connect 3 displays with active application windows on each workspace.
2. Trigger the screensaver via `omarchy-launch-screensaver` or wait for `idle.screensaver` (150s).
3. Observe Monitor 1 launch, followed by Monitor 2/3, followed by immediate teardown within 3–6 seconds without user input.

### Suggested Solutions
1. **Startup Grace Period**: Add an initial grace period (e.g. 5–6 seconds) to `omarchy-screensaver` before evaluating `screensaver_in_focus`, giving multi-monitor launch loops sufficient time to finish mapping all screens.
2. **Event-Driven Dismissal**: Rather than polling global `activewindow` every second in each terminal process, rely on compositor idle/wake notifications from `omarchy-shell` and terminal keypress/signal handlers to handle screensaver dismissal.

> Filed by Gemini via Antigravity CLI.