## What happened

On a Dell Pro Max 16 with a Broadcom ControlVault 3+ fingerprint reader, `omarchy setup security fingerprint` exits immediately with:

```
No fingerprint sensor detected.
```

The reader is plainly present, and Broadcom ships a driver that names this exact USB ID.

## Root cause

`omarchy-hw-fingerprint` reads only the **device** product descriptor:

```bash
if [[ -r $dev/product ]]; then
    product=$(<"$dev/product")
```

On this reader that string is a bare model number. The human-readable name lives in the **interface** descriptor instead:

```
$ cat /sys/bus/usb/devices/3-8/product
58200
$ cat /sys/bus/usb/devices/3-8/3-8:1.0/interface
Broadcom ControlVault 3+ w/FingerPrint
```

So the `*fingerprint*` substring test never sees the word — the lowercasing in the script is correct, the string simply isn't in the file being read. The vendor-ID fallback doesn't fire either, because Broadcom's `0a5c` is not in `fingerprint_vendors`.

For completeness, `has_kernel_driver` would not have excluded it — nothing is bound to the interface:

```
$ ls /sys/bus/usb/devices/3-8/3-8:1.0/driver
ls: cannot access '...': No such file or directory
$ cat /sys/bus/usb/devices/3-8/3-8:1.0/bInterfaceClass
fe
```

## Suggested fix

Extend the existing product-string test to also scan interface descriptors. This preserves the current "a device that names itself a fingerprint reader is trusted outright" rule and adds no new vendor IDs:

```bash
for intf in "$dev"/*:*; do
  [[ -r $intf/interface ]] || continue
  name=$(<"$intf/interface"); name=${name,,}
  [[ $name == *fingerprint* || $name == *biometric* ]] && exit 0
done
```

Verified on this machine: it matches `0a5c:5865` and nothing else (8 USB interfaces scanned, 1 match).

Adding `0a5c` to `fingerprint_vendors` would also fix detection, but seems worse — Broadcom makes plenty of non-reader USB silicon, whereas the interface-string match is self-limiting.

## A caveat worth deciding on

Detection is necessary but not sufficient here. Stock `libfprint` has no ControlVault driver ([supported devices](https://fprint.freedesktop.org/supported-devices.html) lists no `0a5c` entries), so once detected, setup would proceed to `omarchy-pkg-add libfprint fprintd usbutils` and then fail at `fprintd-enroll`.

The script already anticipates exactly this shape of failure — the comment about Elan MOC sensors, and deferring PAM edits until after a successful enroll+verify — so it would fail gracefully rather than leaving a broken PAM stack. But the outcome on this hardware would still be "cannot complete", just with an accurate reason instead of a false one.

Driving this reader needs the out-of-tree TOD stack (`libfprint-tod` + Broadcom's `libfprint-2-tod1-broadcom-cv3plus`, whose udev rules name `0a5c:5864`–`5867` explicitly). That is the same underlying limitation as #7006, where setup hardcodes the stock libfprint stack and breaks on `open-fprintd`.

**This issue is narrowly about the detector reporting "no sensor" when one is present.** Fixing it turns a misleading message into an accurate one; making setup actually succeed on these machines is the broader problem in #7006. Happy to send a PR for the detector change if that's useful.

## Steps to reproduce

On any Dell laptop with a ControlVault 3+ reader (`0a5c:586*`):

1. `omarchy-hw-fingerprint; echo $?` → `1`
2. `omarchy setup security fingerprint` → `No fingerprint sensor detected.`

## Environment

- Omarchy 4.0.0-1
- Kernel 7.1.8-arch1-3
- Dell Pro Max 16 MC16250
- CPU: Intel Core Ultra 7 265H
- GPU: Intel Arc integrated (i915) + NVIDIA RTX PRO 1000 Blackwell Laptop
- Sensor: `0a5c:5865` — Broadcom ControlVault 3+ w/FingerPrint (BCM58200)

No `omarchy debug` log is attached: `debug` is listed under Groups in `omarchy --help`, but running it on 4.0.0-1 returns `Unknown Omarchy command: omarchy debug`. Possibly worth a separate issue.