## What happened

`omarchy setup security fingerprint` cannot complete on a laptop whose fingerprint
reader is present on the USB bus but has **no driver in libfprint at all**. The
command's hardware gate passes, it proceeds to package install, and then dies at
the enroll step with a low-level D-Bus error that says nothing about the actual
cause:

```
Impossible to enroll: GDBus.Error:net.reactivated.Fprint.Error.NoSuchDevice: No devices available
```

The machine is an HP EliteBook 8470w with a **Validity Sensors VFS491 (`138a:003d`)**
swipe reader.

`omarchy-hw-fingerprint` returns 0 (reader present), because `138a` is in
`fingerprint_vendors` and the device has no kernel driver bound to its interface —
exactly the vendor-ID heuristic the script documents. But stock `libfprint 1.94.100`
only carries Validity drivers for VFS0050, VFS101, VFS301, VFS5011 and VFS7552.
VFS491 is not among them, so `fprintd` enumerates zero devices and there is nothing
for `fprintd-enroll` to talk to.

`omarchy-setup-security-fingerprint` already anticipates this class of failure in a
comment:

> Detection only proves a reader is there, not that libfprint can drive it — an Elan
> MOC sensor outside the elanmoc table gets this far and then fails to enroll.

That reasoning is used to justify deferring the PAM edits until after a successful
enroll and verify — which works correctly here, nothing in `/etc/pam.d/` was touched.
But the same reasoning argues for failing *before* `omarchy-pkg-add`, with a message
that names the sensor.

## Steps to reproduce

1. Boot Omarchy on a machine with a `libfprint`-unsupported reader (here `138a:003d`).
2. Run `omarchy setup security fingerprint`.
3. The sensor check passes — no "No fingerprint sensor detected." message.
4. `omarchy-pkg-add libfprint fprintd usbutils` runs.
5. Enrollment fails immediately with `NoSuchDevice: No devices available`.
6. The script exits 1 after printing "Enrollment failed. Please try again." —
   which is misleading advice, since retrying can never succeed.

Verified state on this machine:

```
$ omarchy-hw-fingerprint; echo $?
0

$ lsusb | grep 138a
Bus 004 Device 003: ID 138a:003d Validity Sensors, Inc. VFS491

$ systemctl start fprintd && fprintd-list $USER
No devices available

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

All three packages were already installed here, so step 4 was a no-op — the failure
is purely the enumeration gap, not a packaging problem.

## What I expected

The command should detect that no libfprint-drivable device exists and abort before
installing anything, with a message naming the unsupported reader, e.g.:

```
Fingerprint reader 138a:003d (Validity VFS491) is not supported by libfprint.
No fingerprint device is available to enroll against.
```

## Suggested fix

Gate on **actual fprintd enumeration**, not sysfs vendor-ID presence. After
`omarchy-hw-fingerprint` passes and packages are present, check that fprintd reports
at least one device before attempting enrollment:

```bash
if ! fprintd-list "$USER" &>/dev/null && \
   fprintd-list "$USER" 2>&1 | grep -q "No devices available"; then
  echo -e "\e[31mReader detected, but libfprint has no driver for it.\e[0m"
  lsusb | grep -iE "$(printf '%s|' $fingerprint_vendors)" >&2
  exit 1
fi
```

(Or query `net.reactivated.Fprint.Manager.GetDevices` over D-Bus directly, which
avoids parsing an error string.)

This would also turn the confusing failure in #10309 (EgisTec EH570) and #7006
(ThinkPad `06cb:009a`) into a clear one, since both are the same shape: reader
present, libfprint unable to drive it.

## No viable driver exists for this sensor

Noting this so the issue isn't triaged as "install the out-of-tree driver":

- The only driver that lists `0x003d` is the AUR `libfprint-vfs_proprietary-git`
  (`VALIDITY_PRODUCT_ID_491 = 0x003d` in `vfs_proprietary.h`).
- It hard-depends on `vfs495-daemon`, which **no longer exists in the AUR** — the
  package cannot be built.
- It is a `libfprint` **0.99.0** fork declaring `conflicts=(libfprint)`. Installing it
  would remove `fprintd`, which requires `libfprint-2.so=2-64`, defeating the purpose.

So on this hardware the correct outcome is a clean, early, informative failure —
which is what this issue asks for.

## System details

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Kernel | 7.1.9-arch1-2 |
| Machine | HP EliteBook 8470w |
| CPU | Intel Core i7-3630QM |
| GPU | AMD Radeon HD 7550M/7570M/7650M (radeon) |
| Hyprland | 0.56.2 |
| libfprint | 1.94.100-1 |
| fprintd | 1.94.5-2 |
| Sensor | Validity Sensors VFS491 `138a:003d` (bcdDevice 1.04, no iProduct string) |

## Related

- #10309 — EgisTec EH570: detected, driver present but hangs during enroll.
- #7006 — ThinkPad `06cb:009a`: unsupported by libfprint, needs open-fprintd.
- #10091 — Validity VFS5011: aborts before PAM when verify can't claim the reader.

Distinct from all three: here libfprint has no driver for the device whatsoever, so
fprintd enumerates zero devices — the cheapest possible case to detect up front.