Restore FPC fingerprint detection in Quattro (#6737)

* Restore FPC fingerprint detection

* Anchor the FPC product match to a prefix

*fpc* is an unanchored three-letter token on the one branch that is
trusted outright, with none of the kernel-driver checking the vendor
guess gets. Every FPC reader on record leads with it — "FPC Sensor
Controller", "FPC Sensor Controller L:0002 FW:25.26.23.14", and this
branch's "FPC L:0000 FW:1425046" — so requiring the prefix costs no
coverage while keeping three letters from matching mid-string, where
FPC abbreviates unrelated things like flexible printed circuit.

Also restore the note about why Elan is kept out of the vendor list, so
the two signatures read as the same deliberate exception.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Write no product descriptor for a two-field device spec

${remainder#*:} returns the string unchanged when there is no second
colon, so a spec meant to describe a device with no product descriptor
wrote the product id out as its product string instead. Every call site
happened to pass a trailing colon, so the suite was right by accident.

Guard the split and drop the trailing colons, so the two vendor-match
cases exercise the path they were written for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Bind a named driver in the kernel-driver fixture

Touching a bare `driver` file asserts that any driver at all disqualifies
a vendor guess, which is more than the detector should promise: libusb
claims an interface through a synthetic `usbfs` driver, so a reader in
active use looks bound by that rule.

Link the interface at a named driver directory instead, the way sysfs
does. The case still covers what it was written for — a Synaptics bridge
or a camera on a fingerprint vendor ID — without fixing the shape of the
answer for drivers it was never about.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

bin/omarchy-hw-fingerprint

@@ -9,6 +9,7 @@
 # also make USB touchscreens) are left out to avoid nagging laptops with no
 # reader — those still match on the product string below when present.
 fingerprint_vendors=" 27c6 138a 06cb 08ff 1c7a 147e "
+usb_devices_path="${OMARCHY_USB_DEVICES_PATH:-/sys/bus/usb/devices}"
 
 # libfprint drives every reader it supports from userspace over libusb, so a
 # real reader sits there with no kernel driver bound to any of its interfaces.
@@ -24,16 +25,19 @@ has_kernel_driver() {
   return 1
 }
 
-for dev in /sys/bus/usb/devices/*; do
+for dev in "$usb_devices_path"/*; do
   # The device's own product descriptor usually names it, e.g. "Goodix
   # Fingerprint USB Device" — driver-independent and vendor-agnostic.
   if [[ -r $dev/product ]]; then
     product=$(<"$dev/product")
     product=${product,,}
-    # Elan's match-on-chip readers report "ELAN:ARM-M4", the family name
-    # rather than the function. Elan is left out of the vendor list above
-    # on purpose, so without this they match nothing.
-    [[ $product == *fingerprint* || $product == *biometric* || $product == *elan:arm-m4* ]] && exit 0
+    # Elan's match-on-chip readers report "ELAN:ARM-M4" and Fingerprint Cards'
+    # report "FPC Sensor Controller" or "FPC L:0000 FW:1425046" — the family or
+    # the manufacturer rather than the function. Both vendors are left out of
+    # the list above on purpose (Elan also makes touchscreens), so without these
+    # they match nothing. FPC leads the string on every reader on record, and
+    # three letters are little to match on, so require the prefix.
+    [[ $product == *fingerprint* || $product == *biometric* || $product == *elan:arm-m4* || $product == "fpc "* ]] && exit 0
   fi
 
   if [[ -r $dev/idVendor ]]; then