### System details

ThinkPad T480 (DMI `20L5S04M00`), Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Intel UHD Graphics 620, i7-8550U

### What's wrong?

`omarchy setup security fingerprint` reports that a sensor was detected, prompts for a sudo password, and then fails with a raw GDBus error:

```
Setting up fingerprint scanner for authentication.

Let's setup your right index finger as the first fingerprint.
Keep moving the finger around on sensor until the process completes.

[sudo] password for dchichorro:
Impossible to enroll: GDBus.Error:net.reactivated.Fprint.Error.NoSuchDevice: No devices available
```

The reader is real and the kernel sees it fine:

```
$ lsusb | grep -i synaptics
Bus 002 Device 001: ID 06cb:009a Synaptics, Inc. Metallica MIS Touch Fingerprint Reader

$ usb-devices
P:  Vendor=06cb ProdID=009a Rev=01.64
S:  SerialNumber=440e9486171b
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
```

Vendor `06cb` is a multi-purpose vendor, and `omarchy-hw-fingerprint` guesses on the **vendor ID** alone:

```bash
# /usr/share/omarchy/bin/omarchy-hw-fingerprint:13
fingerprint_vendors=" 27c6 138a 06cb 08ff 1c7a 147e "
```

So the check passes. But libfprint has exactly one Synaptics driver, and its `id_table` (checked both at the pinned rev `6f9479c` and at current `master`) covers only `06cb:00BD`–`06cb:01A4`:

```c
static const FpIdEntry id_table[] = {
  { .vid = SYNAPTICS_VENDOR_ID,  .pid = 0x00BD,  },
  ...
  { .vid = SYNAPTICS_VENDOR_ID,  .pid = 0x01A4,  },
  { .vid = 0,  .pid = 0,  .driver_data = 0 },   /* terminating entry */
};
```

`06cb:009a` is not in that list, and in no other driver, so libfprint claims nothing and `fprintd` enumerates zero devices. There is no amount of reinstalling `libfprint-git`/`fprintd` that fixes it — the reader has no upstream Linux driver (it's on libfprint's [Unsupported Devices](https://gitlab.freedesktop.org/libfprint/wiki/-/wikis/Unsupported-Devices) wiki). The AUR forks don't cover it either: `3v1n0/libfprint` branch `tod` and `rindeal/libfprint-vfs_proprietary` are both 138a/Validity only.

### Steps to reproduce

1. On a laptop with a Synaptics reader whose PID libfprint does not support (e.g. `06cb:009a`).
2. `omarchy setup security fingerprint`.
3. Observe: sudo prompt, then `No devices available`, and the generic `Enrollment failed. Please try again.`

Nothing is left half-configured — the script bails at `omarchy-setup-security-fingerprint:90` before it writes any PAM changes, which is correct. But the user is sent through a sudo prompt and a physical enrollment attempt first, and the error they get names D-Bus rather than the actual cause (no driver for this reader).

### Logs

```
$ pacman -Q libfprint-git fprintd
libfprint-git 1:1.94.100.r10.g6f9479c-1
fprintd 1.94.5-2

$ omarchy-hw-fingerprint; echo $?
0

$ fprintd-enroll "$USER"
Impossible to enroll: GDBus.Error:net.reactivated.Fprint.Error.NoSuchDevice: No devices available

$ busctl get-property net.reactivated.fprintd /net/reactivated/fprintd \
    net.reactivated.fprintd fprintd.devices
a{sv} 0
```

### Possible fix

A few options, in rough order of preference:

1. **Ask fprintd, don't guess.** Before prompting for sudo, check that the service actually sees a device (e.g. `fprintd.devices` is non-empty over D-Bus). That is authoritative and costs one D-Bus round trip, and it makes the vendor list a fallback for the "before fprintd is installed" case the comment describes rather than the primary test.
2. **Reorder the script** so the pre-flight check happens before the sudo password prompt and before `fprintd-enroll`, and translate `NoSuchDevice` into something actionable — "reader present, but no libfprint driver supports it; see <unsupported devices list>" instead of `Enrollment failed. Please try again.`
3. **Narrow the guess.** `06cb` in `fingerprint_vendors` is what makes this a false positive; the supported PIDs are a known finite set. If the list is kept for the pre-fprintd case, a product-string allowlist (as already done for Elan/FPC) would cover this device honestly: it self-identifies as a fingerprint reader, but `06cb` also ships touchpads, touchscreens and USB bridges, and the vendor-only rule accepts all of them.

Note that several readers already report the *opposite* failure (detected correctly by libfprint but missed by the guess) — #11426, #11384, #7535. Option 1 fixes both directions at once.