## What happened

When the idle timer reaches the configured `idle.lock` timeout, the lock screen is never actually shown — the screen stays fully unlocked and accessible, even though the internal scripts report success. Locking manually (`omarchy system lock`) and locking via suspend both work correctly. Only the automatic idle-timeout path is affected.

## Expected behavior

When idle time exceeds `idle.lock` (in `~/.config/omarchy/shell.json`), the session should lock, same as a manual `omarchy system lock`.

## Steps to reproduce

1. Set a short `idle.lock` in `~/.config/omarchy/shell.json` for testing (default is 300s).
2. Leave the machine untouched (no keyboard/trackpad/power-button input) until the configured lock timeout elapses.
3. Observe: no lock screen appears. Check `omarchy-shell lock status` afterward — it still reports the state from before the idle period, with no `lock-requested`/`secure=true` transition logged.

Compare with:
- `omarchy system lock` run manually — locks correctly every time.
- Closing the lid / suspending — locks correctly on resume.

## Root cause (as far as I could trace it)

- The idle module's `lock-timeout` event correctly spawns `omarchy-system-lock` (confirmed via `journalctl --user _COMM=quickshell`), which exits with `status 0`.
- `omarchy-system-lock` triggers the lock via `omarchy-shell lock lock >/dev/null` — an IPC call sent back into the same Quickshell process that just spawned it as a child.
- On the automatic idle path, this self-referential IPC call appears to fail silently. No `lock-requested` or `secure=true` is ever logged by the lock module (the `"omarchy lock"` log namespace stays completely silent), unlike a manual invocation, which logs the full `lock-requested` → `secure=true` sequence within ~1s.
- The failure is invisible because:
  - `omarchy-shell`'s IPC wrapper treats any output that doesn't match its known failure-string patterns as success (exit 0), per its own comment: *"qs reports connection failures with a nonzero exit, but IPC-level failures (unknown target/function, bad arguments) go to stdout with exit 0."*
  - `omarchy-system-lock` redirects that call's output to `/dev/null` and never checks its exit status.
- Net effect: the idle-triggered lock script "succeeds" from the shell's point of view, but the lock screen never engages.

## Evidence

Log from a clean reproduction (nothing touched during the idle period):

```
20:21:43.146  omarchy idle: lock-system: lock-timeout
20:21:43.146  omarchy idle: process-start: lock omarchy-system-lock
20:21:44.787  omarchy idle: process-exit: lock exitCode=0 status=0
```

`omarchy-shell lock status` immediately after:

```json
{"locked":false,"requested":false,"pending":false,"sessionLocked":false,"secure":false, "lastEvent":"unlocked", "lastEventAt":"<timestamp from an earlier manual lock, unchanged>"}
```

No `lock-requested`, `secure=`, or any other lock-module log line appears between the `lock-timeout` and this status check — the lock module was never actually engaged.

For contrast, a manual `omarchy system lock` run from a shell produces the expected full sequence:

```
lock-requested
lock-pending: screen-stabilizing
secure=true
```

## System info

- Omarchy channel: `dev`
- Omarchy version: `dev`
- Hyprland: 0.56.2
- Quickshell: 0.3.1 (Arch Linux build)
- Kernel: 7.1.9-arch1-2
- CPU: Intel Core i7-9750H
- GPU: Intel UHD Graphics 630 + NVIDIA GeForce GTX 1650 Mobile (Max-Q), hybrid graphics laptop

`idle.lock` and `idle.screensaver` in `shell.json` are set to their working defaults (300 / 150) and fire on schedule — this is not a config/timing issue, the timeout is correctly detected each time, only the resulting lock action fails silently.