### What's happening

The screensaver (`omarchy-screensaver`) only wakes on an actual printable keystroke. A bare `Ctrl` tap and mouse clicks/movement don't wake it.

### Root cause

`omarchy-screensaver`'s exit loop only reacts to a byte read from the terminal's stdin:

```bash
while pgrep -t "${tty#/dev/}" -x ttfx >/dev/null; do
    if read -n1 -t 1 || ! screensaver_in_focus; then
      exit_screensaver
    fi
done
```

- `Ctrl` alone never sends a byte at the tty level (it's a modifier with no keysym of its own), so `read -n1` never returns for it.
- Mouse clicks aren't tty input at all, so they're invisible to this loop. `screensaver_in_focus` doesn't help either, since the screensaver is fullscreen with nothing else to focus by clicking.

Separately, `plugins/services/idle/Service.qml`'s `handleActiveSignal()` explicitly *ignores* Wayland-level idle-notify activity while the screensaver window exists:

```js
function handleActiveSignal() {
  if (root.screensaverStartedThisCycle && (root.screensaverWindowCount > 0 || ...)) {
    logEvent("idle-monitor-active", "screensaver cycle remains armed")
    return   // activity signal dropped on the floor
  }
  cancelIdleCycle("activity")
}
```
(That's deliberate — launching the screensaver window itself trips idle-notify, and this avoids a self-close-on-launch loop. But the side effect is that *all* compositor-level activity, including real mouse/keyboard activity, is swallowed for as long as the window is up.)

### Known history

I found in the v3.3.0 changelog that mouse-to-wake existed before and was intentionally removed:

> "Fix screensaver not working when using bluetooth mice by, unfortunately, having to remove mouse-to-wake" — v3.3.0

So I'm not proposing to blindly re-add global mouse-to-wake. Two separable, smaller fixes:

**1. Bare Ctrl tap** — unrelated to the Bluetooth-mouse history (it's a keyboard modifier key, not mouse input at all). I added this locally as a Hyprland Lua bind on `Control_L`/`Control_R` (release-triggered, so it doesn't fire mid-combo) that sends the screensaver process the same `SIGHUP` its own `exit_screensaver` trap already handles. Zero risk of the BT-mouse regression since no mouse code path is touched.

**2. Scoped mouse-click wake** — instead of a global idle-notify/mouse-motion listener (which is presumably what broke for Bluetooth mice, if the issue was event delivery reliability/latency from BT devices at the libinput layer), I scoped it narrowly: a Hyprland `mouse:272/273/274` click bind that only exists while an `org.omarchy.screensaver` window is open, added on `window.open` and removed on `window.close`/`window.destroy` (mirrors the existing selection-layer bind pattern in `bindings/utilities.lua`). This still depends on the click event reaching Hyprland at all, so if the original bug was "BT mouse clicks/motion don't reach the compositor promptly," this narrower version could hit the same wall — flagging that honestly rather than claiming it's a guaranteed fix. But it's worth reconsidering given it only intercepts clicks (not raw motion) and only while the screensaver is already up, which is a smaller surface than whatever the original implementation did.

### Repro

1. Let the screensaver kick in (or `omarchy-launch-screensaver force`).
2. Tap `Ctrl` alone, or click the mouse. Screensaver stays up.
3. Type any character. Screensaver closes.

### Suggested fix

Happy to open a PR with the two pieces above (tested locally, working) if useful — or if there's a reason mouse-click-only (vs. motion) still isn't safe for BT mice, I'd like to understand that constraint before proposing the mouse half further.