# ISSUE — Lock screen fingerprint sensor only ever runs ONE pam session per lock

## Summary

The Omarchy lock screen (`shell/plugins/lock/Service.qml`) creates a single Quickshell `PamContext` for fingerprint auth and never starts a second one for the duration of a lock. After the first scan returns no-match or the driver errors, `fingerprintPam.active` stays truthy, so `startFingerprint()` bails out of every later attempt. Result: **fingerprint unlock works at most once per lock**, and if your first press misses (finger slipped, touched early, reader was still warming up), the reader is dead until you unlock by password and lock again.

## Reproduction

Omarchy 4.0.4, laptop with an integrated fingerprint reader (tested: Broadcom ControlVault 3, USB `0a5c:5843`, via `libfprint-2-tod1-broadcom` / fprintd 1.94.5).

1. Enroll a finger, lock.
2. Press the reader and get a miss/no-match (or wait out the 30s window without touching).
3. Press again — nothing happens, until you unlock with the password.

Details that make it visibly worse on this hardware:

- The reader needs the driver warmed up to take a pass, so the first press in a new lock often errors (`Identification failed due to unforeseen error` after ~10s). With the current design that one error is fatal for the whole lock.
- The lock keeps the fingerprint PAM armed (scanning) continuously while the display is blanked, which drives the Broadcom 58200 into its thermal cutoff (`Device disabled to prevent overheating`) after a few minutes of being locked.

## Evidence

fprintd debug logs across one lock, stock Omarchy:

```
15:01:45 identify()            <- first (and only) session
15:01:55 Identification failed due to unforeseen error!
... user holds a finger for 60s after wake ...
15:02-15:06 (nothing)           <- reader never re-arms
```

And with the fix below:

```
15:11:17 session #1: identify() -> errors after 10s
15:11:27 session #2+ re-arm on the 250ms retry
15:14:10 fresh session on wake
15:14:18 verify-match            <- unlock works after a miss, after walking away
```

## Root cause

`Service.qml` uses a single `PamContext { id: fingerprintPam }` whose `active` never returns to `false` after a completed/errored session within one lock. The retry `Timer` fires every 250ms but `startFingerprint()` guards on `fingerprintPam.active || fingerprintAuthenticating` and returns forever.

## Proposed fix

See PR (re-arm manages a fresh `PamContext` per attempt):

- Replace the single `PamContext` with a `Component` factory creating a new instance per attempt.
- While the display is blanked (`runBlank`), stop the retry timer and gate `startFingerprint()` on the existing `displaysBlank` state so no NEW scan starts while the sensor is idle and could overheat; re-arm on wake (`runWake`). An in-flight scan is left to finish — the reader is not a compositor wake source, and aborting the pam session in `runBlank` severed a scan that the driver was still servicing, leaving the reader dead until password unlock.

## Notes

- This is not reader-specific: any fingerprint reader that errors or misses on its first scan of a lock is affected. The thermal behavior just makes the first-scan error common on some TOD/LS drivers.