### What happened

Two related fingerprint-auth problems on a Dell Precision 7740 (Broadcom
BCM58200 ControlVault, `libfprint-2-tod1-broadcom`):

**1. Unbounded fingerprint retry loop overheats/disables the sensor**

`Service.qml`'s lock-screen fingerprint flow retries on every failure via a
fixed, unconditional 250ms timer with no backoff and no failure limit:

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

Both `handleFingerprintFinished()`'s failure branch and `fingerprintPam.onError`
call `fingerprintRetryTimer.restart()` unconditionally. With the screen locked
overnight (~13 hours), this produced **108,724** consecutive
`Device reported an error during identify: Device disabled to prevent
overheating.` lines in the `fprintd` journal — the sensor's own firmware
protection kicked in, and the retry loop kept hammering it anyway, non-stop,
all night, at roughly 4 attempts/second. `journalctl -u fprintd` for that boot:

```
Sep 28 19:00:23 fprintd[37666]: Device reported an error during identify: Device disabled to prevent overheating.
Sep 28 19:00:24 fprintd[37666]: Device reported an error during identify: Device disabled to prevent overheating.
... (108,724 total, continuing until:)
Sep 29 07:51:06 fprintd[37666]: Device reported an error during identify: Device disabled to prevent overheating.
```

No occurrences in any of the 3 prior boots — this was triggered by a single
locked session left overnight. The retry loop has no awareness that the
device is repeatedly, immediately failing and never backs off.

**2. Fingerprint via polkit never actually captures — ~51s late**

Separately, fingerprint auth for polkit prompts (tested via `pkexec` and via
GNOME Disks' native udisks2/D-Bus flow, so not a `pkexec`-specific issue)
never actually completes: the fingerprint icon is shown correctly, and
`fprintd` detects the chip immediately, but the real
`Capture Initiated, Please place your finger now on the sensor now` line —
the one that actually starts listening to the hardware — doesn't fire until
**~51 seconds** after `polkit-agent-helper`'s own session has already logged
`Deactivated successfully` and given up:

```
08:09:13  polkit-agent-helper starts, fprintd detects CID7 chip (normal, fast)
08:09:15  polkit-agent-helper: Deactivated successfully   (session already over)
   ...    51s gap, nothing logged
08:10:18  fprintd: Capture Initiated, Please place your finger now on the sensor now
08:10:18  fprintd.service: Deactivated successfully
```

Sudo and the lock screen never show this delay (chip detection and
`Capture Initiated` land in the same second). Something specific to running
inside `polkit-agent-helper`'s process/session scope stalls the actual
capture call. This may well be a downstream consequence of (1) — if the
sensor was still recovering from the overheating protection, or if `fprintd`
has a queue that the runaway lock-screen retries were still occupying — but
it's reproducible independent of that specific overnight incident too.

### Expected behavior

- The lock screen's fingerprint retry should back off (exponentially, or at
  minimum stop after N consecutive failures) instead of retrying forever at a
  fixed 250ms interval, especially once the driver reports the device itself
  is refusing requests.
- Fingerprint should be able to actually complete a capture within a normal
  polkit authentication window when triggered by a real GUI action, not just
  by `sudo`/the lock screen.

### System info

- Omarchy 4.0.4-1
- Dell Precision 7740, Broadcom BCM58200 ControlVault (`0a5c:5843`), Citadel A0
  CID7, AAI 5.15.21.0 / SBI 240
- `libfprint-2-tod1-broadcom` 5.15.021.0-1, `fprintd` 1.94.5-2,
  `libfprint-tod` 1.95.2+tod1-1
- Kernel 7.2.5-3-omarchy, Hyprland 0.56.2, SDDM, quickshell 0.3.1-1

### Steps to reproduce

**(1):** Enroll a fingerprint, lock the screen, and leave it locked for
several hours without touching the sensor. Check `journalctl -u fprintd` for
a flood of retry/error lines.

**(2):** Set up fingerprint for polkit per `omarchy setup security
fingerprint` (or manually, matching its template for
`/etc/pam.d/polkit-1`). Trigger any polkit prompt (e.g. GNOME Disks → Edit
Mount Options) and touch the sensor when the fingerprint icon appears.
Compare `journalctl -u fprintd` / `journalctl -t polkit-agent-helper-1`
timestamps for chip detection vs. `Capture Initiated` vs. the helper's own
`Deactivated successfully`.

### Suggested fix for (1)

Add a per-lock-session failure counter with exponential backoff and a hard
retry cap, instead of an unconditional fixed 250ms restart. Rough sketch
against `Service.qml`:

```qml
property int fingerprintFailureCount: 0
readonly property int fingerprintMaxRetries: 20
readonly property int fingerprintBaseIntervalMs: 250
readonly property int fingerprintMaxIntervalMs: 30000

function fingerprintBackoffInterval() {
  var interval = fingerprintBaseIntervalMs * Math.pow(2, Math.min(fingerprintFailureCount, 10))
  return Math.min(interval, fingerprintMaxIntervalMs)
}

function scheduleFingerprintRetry() {
  fingerprintFailureCount += 1
  if (fingerprintFailureCount > fingerprintMaxRetries) return // give up until next lock
  fingerprintRetryTimer.interval = fingerprintBackoffInterval()
  fingerprintRetryTimer.restart()
}
```

`handleFingerprintFinished()` would reset the counter to 0 on success and call
`scheduleFingerprintRetry()` instead of `fingerprintRetryTimer.restart()` on
failure; `fingerprintPam.onError` would do the same. The counter would also
reset to 0 in `onSecureStateChanged` when a fresh lock session begins, so each
new lock gets a full set of retries rather than being capped by a previous
session's count. Happy to open a PR with this if it's a welcome direction.