### What happened
Once the native screensaver (ttfx, launched via `omarchy-launch-screensaver`) is
showing, moving the mouse does nothing — it keeps running until a key is
pressed *while the screensaver terminal has focus*. On the old hypridle-based
setup, any global input (including mouse movement) dismissed the screensaver
immediately via `on-resume`. This is a regression in day-to-day usability:
grabbing the mouse to check something no longer wakes the screen the way it
used to on every other idle-lock implementation (GNOME, KDE, plain hypridle).

### Root cause
`shell/plugins/services/idle/Service.qml`, `handleActiveSignal()`:

```qml
function handleActiveSignal() {
  if (!root.idledThisCycle) return

  // Starting the screensaver can make the compositor report activity. Keep
  // the lock timer running once the screensaver exists (or during its short
  // launch grace); Hyprland window events cancel the cycle if it exits before
  // the normal lock deadline.
  if (root.screensaverStartedThisCycle && (root.screensaverWindowCount > 0 || screensaverLaunchGraceTimer.running)) {
    logEvent("idle-monitor-active", "screensaver cycle remains armed")
    return
  }

  cancelIdleCycle("activity")
}
```

`screensaverWindowCount > 0` is included in the guard, so **for the entire
time the screensaver window exists**, the idle monitor's activity signal
(which does fire on mouse movement — verified via `logEvent`) is discarded
and `cancelIdleCycle()` is never reached. The comment explains why the guard
exists at all (the screensaver's own window mapping can spuriously report
activity right at launch), but it over-broadly suppresses *all* activity for
the window's entire lifetime, not just the brief launch window.

Even fixing that guard isn't enough on its own: `cancelIdleCycle()` never
actually kills the screensaver process/window — it only stops timers and
calls `omarchy-system-wake` (display brightness). The screensaver window
stays open and unresponsive to anything but its own internal
`read -n1`-based keypress loop (`omarchy-screensaver`), which only sees input
while it holds terminal focus, never mouse motion.

### Expected
Any global input (mouse or keyboard) while the screensaver is up should
dismiss it, matching pre-Quattro `hypridle` behavior and every other
DE's idle-lock.

### Suggested fix (tested locally)
1. Narrow the guard in `handleActiveSignal()` to only the launch grace,
   not the window's entire lifetime:
   ```qml
   if (root.screensaverStartedThisCycle && screensaverLaunchGraceTimer.running) {
   ```
2. Make `cancelIdleCycle()` actually kill the screensaver window when one is
   open:
   ```qml
   if (root.screensaverWindowCount > 0) runProcess(dismissProcess, "dismiss-screensaver", "pkill -f \"[o]rg.omarchy.screensaver\" 2>/dev/null; true")
   ```
   (plus a matching `dismissProcess: Process { ... }` element alongside the
   existing `screensaverProcess`/`lockProcess`/`wakeProcess`).

I've applied this locally via `omarchy plugin clone omarchy.idle` and it
resolves the issue without side effects on lock timing — the screensaver
still ignores activity during its brief launch grace (so it doesn't
self-cancel on its own window mapping), but responds to mouse/keyboard once
it's actually up.

### System
- Omarchy 4.0.0 "Quattro"
- quickshell-git 0.3.0.r20.g28771c7
- Hyprland (Lua config)