## What happened

The lock screen retries fingerprint authentication in an unbounded hot loop when `pam_fprintd` returns an error immediately, generating ~4 PAM sessions per second for as long as the screen stays locked. On a device that libfprint thermally throttles, this is self-sustaining: the retries keep the reader from ever cooling out of its lockout, so fingerprint unlock can never succeed and the only way in is the password.

In one day on my machine this produced **41,498 fingerprint PAM sessions** and **41,324 fprintd errors**, spread across 192 separate lock episodes.

## Cause

`shell/plugins/lock/Service.qml`:

```qml
onError: function(error) {
  root.fingerprintAuthenticating = false
  if (root.lockRequested && root.fingerprintConfigured) fingerprintRetryTimer.restart()
}

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

The retry is a flat 250 ms with no backoff and no cap on consecutive failures. That interval is reasonable when the error is transient (a bad swipe), but `onError` does not distinguish a bad swipe from a device-level failure that will return instantly and identically every time.

Here the device-level failure is libfprint's thermal protection. My reader is a Upek TouchChip/Touchstrip swipe sensor (`147e:2016`), which libfprint 1.94 throttles on duty cycle. Once it trips:

```
fprintd[49676]: Device reported an error during verify: Device disabled to prevent overheating.
```

`pam_fprintd` returns `PAM_AUTHINFO_UNAVAIL` (9) essentially instantly, `onError` fires, the timer re-arms, and 250 ms later it tries again. The device is never idle long enough to cool down, so it stays disabled until the user gives up and types their password.

Log excerpt showing one cycle (they repeat ~4x/second):

```
omarchy-shell[274091]: Starting pam session for user "adam" with config "omarchy-lock-fingerprint" in dir "/etc/pam.d"
omarchy-shell[274091]: Relaying pam message: "Swipe your right index finger across the fingerprint reader" echo: 1 error: 0 responseRequired: 0
omarchy-shell[274091]: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)
omarchy-shell[274131]: Starting pam session for user "adam" with config "omarchy-lock-fingerprint" in dir "/etc/pam.d"
omarchy-shell[274131]: Relaying pam message: "Swipe your right index finger across the fingerprint reader" echo: 1 error: 0 responseRequired: 0
omarchy-shell[274131]: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)
```

The loop stops only on unlock:

```
omarchy-shell[274336]: Starting pam session for user "adam" with config "omarchy-lock-password" in dir "/etc/pam.d"
omarchy-shell[274336]: Relaying pam message: "Password: " echo: 0 error: 0 responseRequired: 1
omarchy-shell[274336]: Authenticated successfully.
```

The hardware itself is fine. Restarting `fprintd` resets libfprint's thermal model, and verification then succeeds on the first swipe:

```
$ sudo systemctl restart fprintd && fprintd-verify
Verify result: verify-match (done)
```

It trips again on the next lock.

## Steps to reproduce

1. Set up fingerprint auth via `omarchy setup security fingerprint` on a reader libfprint thermally throttles (swipe sensors such as the Upek TouchChip are the easy case).
2. Lock the screen and leave it locked.
3. Watch `journalctl -fu fprintd` and `journalctl -f --user | grep pam`.

Expected: a bounded number of retries, or a backoff, and the reader remains usable.

Actual: ~4 PAM sessions per second indefinitely; the reader is disabled for the entire lock and fingerprint unlock never works.

## Expected behaviour

`onError` should treat a device-level error differently from a failed swipe. Some options:

- Exponential backoff on consecutive errors instead of a fixed 250 ms.
- A cap on consecutive failures, after which fingerprint is disabled for the remainder of the lock and the UI falls back to password-only.
- Special-case `PAM_AUTHINFO_UNAVAIL` (`error: 0` with no user interaction, returned faster than any real swipe could complete) as "reader unavailable", not "retry now".

Any of these would also stop the log spam, which is significant on its own — 41k journal lines per day from one component.

## System details

| | |
|---|---|
| Omarchy | 4.0.0-1 |
| Kernel | 7.1.8-arch1-3 |
| Hyprland | 0.56.2 |
| quickshell-git | 0.3.0.r20.g28771c7-1 |
| libfprint | 1.94.100-1.1 |
| fprintd | 1.94.5-2.1 |
| CPU | AMD Ryzen 5 5600X |
| GPU | NVIDIA GeForce RTX 3070 (GA104) |
| Machine | MSI MS-7C84 (desktop, USB reader) |
| Reader | `147e:2016` Upek Biometric Touchchip/Touchstrip |

Note this is a desktop with a USB reader, so the clamshell gate that `omarchy-setup-security-fingerprint` adds to the sudo and polkit stacks isn't a factor. `/etc/pam.d/omarchy-lock-fingerprint` has no such gate in any case — it's `auth required pam_fprintd.so` plus the account include.