## What happened

`omarchy-setup-security-fingerprint` installs stock `libfprint` + `fprintd`
and drives enrollment/verification through the open-source `elan.c` driver.
For the ELAN `04f3:0c4b` fingerprint reader (ThinkPad E14/E15 Gen 3 and
Gen 4, at least), that driver treats the sensor as a swipe sensor and
matches with NBIS/Bozorth3 entirely in software:

```
fprintd-enroll   # completes fine, all stages pass
fprintd-verify   # NEVER matches — Bozorth3 score is exactly 0/24,
                 # every single attempt, regardless of finger, technique,
                 # orientation, or speed
```

25+ verify attempts across multiple sessions, always a literal `0` score
(never even a partial match). The script itself doesn't fail loudly —
enrollment and the first verify both "succeed" from the script's point of
view (`fprintd-verify` just needs one non-zero exit at setup time, and a
lucky first touch can pass), so PAM gets wired up for a reader that then
never reliably authenticates in daily use.

## Why this is a packaging/hardware-detection problem, not a bug in the script's logic

This sensor isn't actually a swipe sensor in the way the open driver
assumes — Lenovo's own Windows driver, and a proprietary Linux
`libfprint-tod` plugin Lenovo ships for it, both drive it as a
**press/area** sensor instead:

```
Broken on this PID:  04f3:0c4b → elan.c (open) → swipe capture → NBIS/Bozorth3 → 0/24
Working on this PID: 04f3:0c4b → libfprint-tod → Lenovo's proprietary driver → "press"
```

Switching drivers (not patching `elan.c`) is what actually fixes it —
confirmed with 10/10 `fprintd-verify` passes after the switch, and
working `sudo`, polkit, and lock-screen auth via the existing Omarchy PAM
setup (no PAM changes needed — `pam_fprintd.so` talks to `fprintd` over
D-Bus regardless of which driver is loaded underneath).

I wrote up the full fix — root cause, step-by-step instructions, a
security note on the proprietary binary involved (verified byte-for-byte
against Lenovo's own download before trusting it), and how to protect the
non-standard packages from being silently touched by `omarchy update` —
here, in case it's useful for anyone else with this hardware:

https://github.com/jcperdomoybarra/thinkpad-elan-04f3-0c4b-fingerprint-fix

I'm not proposing a specific code change to
`omarchy-setup-security-fingerprint` in this issue — mostly flagging that
this PID is a known-bad case for the stock driver, in case the Omarchy
maintainers want to special-case a warning/detection for it the way #7006
covers `06cb:009a`. Happy to help test or discuss if that's of interest.

## Environment

- Omarchy 4.0.0
- Kernel 7.1.8-arch1-3
- ThinkPad E15 Gen 3 (AMD)
- Sensor: `04f3:0c4b` ELAN Microelectronics (`ElanTech Fingerprint Sensor`
  under the open driver)
- Stock stack that fails to match: `libfprint 1.94.100-1`, `fprintd 1.94.5-2`
- Working alternate stack: `libfprint-tod-git 1.95.1+tod1-1`,
  `libfprint-2-tod1-elan 0.0.1-2`, `openssl-1.1 1.1.1.w-11` (all AUR)