**System details:** Framework Laptop 12 (13th Gen Intel Core), Intel i3-1315U / Raptor Lake, UHD Graphics (i915), INSYDE BIOS 03.07. Omarchy 4.0.4-1, kernel 7.2.3-arch1-3, Hyprland 0.56.2.

## What's wrong

`omarchy-sleep-lock.service` fails on **every** suspend/resume cycle and has since at least Aug 15 (263 failures recorded):

```
Sep 24 02:47:18 Framework12 systemd[976]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 20.
Sep 24 02:47:18 Framework12 systemd[976]: Started Lock Omarchy before suspend.
Sep 24 02:47:18 Framework12 systemd-inhibit[838223]: Failed to inhibit: The operation inhibition has been requested for is already running
Sep 24 02:47:18 Framework12 systemd[976]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE
Sep 24 02:47:18 Framework12 systemd[976]: omarchy-sleep-lock.service: Failed with result 'exit-code'.
```

The failure coincides exactly with the start of each resume from suspend. Because the unit is `Restart=always` with `RestartSec=2`, it restarts immediately afterwards and then stays idle. Net effect:

- The intended long-lived logind `delay` inhibit (`systemd-inhibit --what=sleep --mode=delay --who=Omarchy --why="Lock screen before suspend"`) is **never actually held** — it only fails during the sleep window and comes up after wake, so the next suspend begins with no Omarchy delay-inhibit in place.
- Every wake logs a failed unit + restart-churn.

**Expected:** the unit starts once per graphical session, acquires the sleep inhibit, holds it, and only acts when `PrepareForSleep` fires — not log a FAILURE every cycle.

**Steps to reproduce:** start a session, suspend and wake the laptop, then check:

```
systemctl --user status omarchy-sleep-lock.service
journalctl --user -u omarchy-sleep-lock.service   # shows exit-code=FAILURE + "Failed to inhibit ... already running"
```

This occurs on every suspend/wake, independent of the separate kernel-level resume failures on this machine (spd5118/ucsi_acpi) — the service races logind finalizing the wake, and logind rejects the new delay inhibit with `-EBUSY` ("The operation inhibition has been requested for is already running") until the sleep operation has fully settled.

The offending unit: `/usr/lib/systemd/user/omarchy-sleep-lock.service` -> `omarchy-system-sleep-monitor` (which execs `systemd-inhibit ... omarchy-system-sleep-lock` while dbus-monitoring `PrepareForSleep`).