## What happened

On a clamshell machine (lid closed, external monitor — the reader in the deck is unreachable), locking the screen starts an endless fingerprint retry loop. Journal shows a new PAM session every ~30 s, indefinitely (observed for 15–30+ minutes at a time):

```
quickshell.service.pam.subprocess: Starting pam session for user "dsundt" with config "omarchy-lock-fingerprint"
quickshell.service.pam.subprocess: Relaying pam message: "Place your right index finger on the fingerprint reader"
quickshell.service.pam.subprocess: Relaying pam message: "Verification timed out"
quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)
```

Each cycle: the lock plugin starts fingerprint PAM (`shell/plugins/lock/Service.qml` — `fingerprintRetryTimer` is 250 ms, `repeat: false`, re-armed on every failed verify), fprintd's verify times out after ~30 s, and the loop repeats forever. While this runs, the session is locked with no working unlock path except waiting out / typing the password, and the overlapping-retry churn is the trigger chain for the crash reports in #7645 / #13410 (quickshell-mirror/quickshell#969).

## Root cause

`omarchy-setup-security-fingerprint` writes a clamshell gate into the **sudo** and **polkit** stacks — `auth [success=1 default=ignore] pam_exec.so quiet /usr/bin/omarchy-hw-laptop-closed` — so the unreachable reader is skipped and PAM falls through to password. The **lock** stack it writes has no such gate:

```
# /etc/pam.d/omarchy-lock-fingerprint
auth       required                    pam_fprintd.so
account    include                     system-local-login
```

The gate exists in the setup tool and demonstrably works (sudo/polkit behave correctly on this machine), it is just missing from the lock stack. The lock plugin additionally has no retry cap, so the failure retries forever.

## Expected behavior

On a lid-closed machine, the lock should fall back to the password prompt (as sudo/polkit already do) instead of blocking on the unreachable reader every 30 s forever. A retry cap with password-only fallback would also be reasonable defense in depth.

## Suggested fix

Add the clamshell gate to `/etc/pam.d/omarchy-lock-fingerprint` — but with fail-fast semantics (`[success=die default=ignore]`), because with only `pam_fprintd` behind it, the skip-to-success form used in sudo/polkit would unlock without any authentication when the lid is closed. And/or cap `fingerprintRetryTimer` re-arms in `Service.qml` so the lock stops offering fingerprint after N failures.

## Workaround applied locally

Renamed `/etc/pam.d/omarchy-lock-fingerprint` to `.disabled-clamshell` — the lock plugin's own presence check then reports fingerprint as unconfigured and the lock is password-only. Sudo/polkit fingerprint kept (their gates work). Documented at dsundt/Dano-Omarchy docs/HANDOFF.md §30.

## System details

- Omarchy `4.0.0.r6713.ga85e29a-1`, quickshell `0.3.1-1`, Hyprland `0.56.2`
- Lenovo ThinkPad P16s Gen 4 AMD — Synaptics press sensor (in-deck), lid closed, external Samsung G91SD
- Related: #7645 (crash from overlapping retries), #13410 (orphan relaunch), #7172 (claim livelock), #13748 (no-backoff retries)