## What happens

The lock screen arms fingerprint PAM for the entire duration of the lock. On a USB *imaging* reader (DigitalPersona U.are.U 4500, `05ba:000a`, libfprint `uru4000`) this drives libfprint's duty-cycle governor into its cutoff after roughly three minutes, and the reader stops responding for the rest of the lock. Unlocking then requires the password, and the sensor illuminator stays lit the whole time the machine is idle.

Two separate problems combine:

**1. Fingerprint PAM is armed for the whole lock, not just when someone is there.**

`shell/plugins/lock/Service.qml` starts fingerprint verification on `onSecureStateChanged` (L235) and keeps it running until unlock. The existing comment at L428 states this intent directly:

```qml
// Only a password check in flight should hold the display up. The
// fingerprint PAM stays armed for the whole lock, so gating on
// `authenticating` here would keep the panel lit until unlock.
```

That is fine for a laptop match-on-chip sensor, which idles cheaply while waiting. An imaging reader instead illuminates and captures continuously. libfprint 1.94 models device duty cycle in software (`FP_TEMPERATURE_COLD/WARM/HOT` — an estimate, not a hardware sensor) and refuses to verify once the estimate reaches HOT:

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

The estimate only decays while the device is idle, and a whole-lock arm never provides idle time, so it cannot recover while locked. Nothing is physically hot — this is purely libfprint's governor.

**2. `fingerprintRetryTimer` hot-loops on hard device errors.**

`interval: 250` (L358), restarted unconditionally on any failure — `handleFingerprintFinished` (L226) and `onError` (L352). Once the device returns the error above, each verify fails *instantly*, so the 250 ms retry becomes a spin loop with no backoff and no failure cap.

Measured on one 22-minute lock: **2,445 failed verifies**, ~36 per 10 seconds, sustained until the password was entered.

This second issue is device-independent — spinning a 250 ms retry against a hard device error is undesirable on any hardware.

## Expected

The reader should not be scanned while the displays are blanked and nobody can present a finger, and a hard device error should back off rather than spin.

## Steps to reproduce

Requires a libfprint imaging reader (this was a DigitalPersona U.are.U 4500; likely any `uru4000`-class device).

1. Enrol a finger and configure lock-screen fingerprint (`omarchy setup security fingerprint`).
2. Lock with Super+Ctrl+L and leave the machine for more than ~3 minutes.
3. Return and touch the reader.

Observed: the sensor stays illuminated the entire time; touching does nothing; the password is required. `journalctl` fills with `Device disabled to prevent overheating.`

Leaving the reader idle for ~3 minutes lets the estimate decay and it verifies normally again, which confirms the device itself is healthy — `fprintd-verify` returns `verify-match`.

## Suggested fix

Tie the fingerprint scan to display wake rather than to the lock as a whole, and back off on repeated failures. I have this running locally as a fork of the lock plugin:

- `runBlank()` closes the fingerprint window (aborts the PAM context); `runWake()` opens it. Locked with monitors off means no scanning at all.
- A bounded scan-window timer as a backstop.
- Exponential backoff on retry (250 ms doubling to a 10 s cap) replacing the flat restart.

Result on the same hardware: 2 PAM sessions instead of 2,445 failed verifies, zero overheating errors, and unlock 2.4 s after nudging the mouse.

Happy to open a PR if the approach looks right — I did not want to presume the design, since gating on wake changes behaviour for match-on-chip readers too (they would also stop scanning while blanked, which seems desirable but is a behaviour change).

## System details

| | |
|---|---|
| Omarchy | 4.0.1-1 |
| Kernel | 7.1.9-arch1-2 |
| CPU | AMD Ryzen AI MAX+ 395 w/ Radeon 8060S |
| GPU | AMD Strix Halo `[1002:1586]` (rev c1) |
| libfprint | 1.94.100-1 |
| fprintd | 1.94.5-2 |
| Reader | DigitalPersona U.are.U 4500, USB `05ba:000a`, driver `uru4000` |

Most recent change to the file: #6817 ("Blank the lock screen while the fingerprint reader waits").