## What happens

`shell/plugins/lock/Service.qml` restarts the `omarchy-lock-fingerprint` PAM session on a fixed 250ms timer from both failure paths:

```qml
// handleFingerprintFinished(), line 226
} else if (fingerprintConfigured) {
  fingerprintRetryTimer.restart()
}

// PamContext.onError, line 352
onError: function(error) {
  root.fingerprintAuthenticating = false
  if (root.lockRequested && root.fingerprintConfigured) fingerprintRetryTimer.restart()
}

// line 356
Timer {
  id: fingerprintRetryTimer
  interval: 250
  repeat: false
  onTriggered: root.startFingerprint()
}
```

There is no backoff and no cap on consecutive failures. When PAM fails *immediately* rather than blocking for a scan, this becomes a ~4/sec loop that spawns a fresh PAM subprocess each time.

I hit this when fprintd was left holding a stale device object after a suspend/resume, so every `Claim` returned `net.reactivated.Fprint.Error.AlreadyInUse` instantly. One lock session produced 176 denied claims:

```
fprintd[87058]: Authorization denied to :1.588 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed
fprintd[87058]: Authorization denied to :1.589 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed
... (176 total)
```

with the matching storm on the shell side:

```
omarchy-shell[96668]: quickshell.service.pam.subprocess: Starting pam session for user "ktr" with config "omarchy-lock-fingerprint" in dir "/etc/pam.d"
omarchy-shell[96733]: quickshell.service.pam.subprocess: Starting pam session for user "ktr" with config "omarchy-lock-fingerprint" in dir "/etc/pam.d"
omarchy-shell[96736]: quickshell.service.pam.subprocess: Starting pam session for user "ktr" with config "omarchy-lock-fingerprint" in dir "/etc/pam.d"
...
```

## Why it matters

The retry loop keeps the reader permanently busy, so fprintd can neither suspend the device nor re-initialize it, and the fault cannot self-heal. fprintd logged:

```
Unexpected error while suspending device: The device is still busy with another operation, please try again later.
```

The wedged daemon then ignored SIGTERM and needed SIGKILL. Recovery required a manual `systemctl stop fprintd`.

The retry loop is not the root cause of my stale device object — that was fprintd being D-Bus activated during the suspend transition and so failing to install its logind sleep-delay inhibitor. But the loop is what turned a recoverable glitch into a stuck lock screen.

## Steps to reproduce

1. Enroll a fingerprint so `omarchy-lock-fingerprint` is active.
2. Put fprintd into a state where `Claim` fails immediately. Easiest reliable way: hold a claim on the device from another client, so `pam_fprintd` returns `AlreadyInUse` without blocking.
3. Lock the screen.
4. Watch `journalctl -f` — a new PAM subprocess roughly every 250ms for as long as the screen stays locked.

## Expected

Back off on repeated immediate failures, or cap consecutive retries, so a rejected scan (retry is correct) is distinguished from an unusable device (retry is futile and keeps the device busy). An exponential backoff, or simply pausing the fingerprint path after N consecutive sub-threshold failures and leaving password auth available, would prevent the loop.

## System

- Omarchy 4.0.2-1
- fprintd 1.94.5-2, libfprint 1.94.100-1
- Sensor: Synaptics Prometheus MIS Touch Fingerprint Reader (`06cb:00bd`)