## What happened

The first fingerprint attempt after resuming from suspend (and the first
attempt right after a session starts) is reliably rejected. A second attempt
a couple of seconds later succeeds. This is consistent across multiple boots
today.

Journal evidence points to a race between `fprintd` and Omarchy's own
suspend/lock handling:

1. At suspend time, `fprintd` tries to install its own sleep-delay inhibitor
   and fails because Omarchy's `omarchy-system-sleep-lock` inhibitor
   ("Lock screen before suspend") already holds that slot:
   ```
   fprintd[...]: Failed to install a sleep delay inhibitor: GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation inhibition has been requested for is already running
   ```
2. On resume, the first automatic verify from the Quickshell lock screen
   (`omarchy-lock-fingerprint` PAM service) fires before fprintd's view of
   the device has caught up, and fails:
   ```
   fprintd[...]: Device reported an error during verify: Cannot run while suspended.
   ```
3. That failed verify leaves the sensor claimed, so the follow-up release
   also fails, and the user's finger swipe is rejected:
   ```
   quickshell[...]: pam_fprintd(omarchy-lock-fingerprint:auth): ReleaseDevice failed: Release failed with error: The device is still busy with another operation, please try again later.
   ```

I also caught one worse episode where the sensor's own firmware
overheat-protection tripped (`Device disabled to prevent overheating`) and
something kept retrying the verify once a second for about 14 minutes
straight with no backoff, until the machine suspended again. That looks like
a symptom of the same underlying "verify fires before the device/claim state
is actually ready" issue, not real heat.

Full excerpt (representative lines from 3 separate boots today) attached.

## What was expected

Fingerprint unlock to work on the first attempt after resume, the same as
subsequent attempts later in the session.

## Steps to reproduce

1. Enroll a fingerprint (`fprintd-enroll`) with the Quickshell lock screen
   wired up (`omarchy apply lock` / `omarchy setup security fingerprint`).
2. Suspend the laptop (lid close or `omarchy system lock` + suspend).
3. Resume and, at the lock screen, place the enrolled finger on the sensor
   immediately.
4. Observe the first scan is rejected; a second attempt a couple of seconds
   later succeeds.

## System details

- Omarchy version: 4.0.2-1
- Laptop: Lenovo ThinkBook 14 G9 IRL
- Fingerprint sensor: Goodix 27c6:550a (match-on-chip; requires the
  proprietary TOD driver — not affected by driver choice, same behavior with
  `libfprint-tod` + `libfprint-2-tod1-goodix-v2` from AUR and official
  `fprintd`)
- `omarchy debug --no-sudo --print` output attached separately

## Notes

- SDDM is set to autologin for this user, so the session never actually
  prompts for fingerprint at the SDDM greeter — the first fingerprint prompt
  a user hits is Omarchy's own Quickshell lock screen right after session
  start or after resume, which is where this reproduces.
- Journal excerpt and full debug log are attached to this issue.