## Enrolled fingerprint is permanently erased after suspend/resume (Goodix MOC 27c6:6594)

### Environment
- Omarchy version: 4.0.0.alpha
- Kernel: 7.2.3-arch1-3
- Reader: Goodix MOC Fingerprint Sensor, USB ID `27c6:6594` ("Goodix USB2.0 MISC")
- `libfprint-git` 1:1.94.100.r10.g6f9479c-1, `fprintd` 1.94.5-2
- Suspend mode: `s2idle`

### Summary
After enrolling a fingerprint via `omarchy-setup-security-fingerprint`, `fprintd-list` eventually reports **"User X has no fingers enrolled"** — with no user action (no `fprintd-delete`, no package reinstall). This has happened twice, and both times correlates exactly with a suspend/resume cycle.

### Timeline (first occurrence)
- `2026-09-09 18:37` — enrolled successfully via `omarchy-setup-security-fingerprint`.
- `2026-09-13 17:13:44` — kernel logs `usb 3-7: usbfs: process (fprintd) did not claim interface 0 before use`, at the exact same second as `kernel: PM: suspend exit`.
- `2026-09-13 17:13:47` — `pam_fprintd(omarchy-lock-fingerprint:auth): No prints enrolled` (first occurrence of this message in the journal).

### Timeline (second occurrence, after re-enrolling)
- `2026-09-14 14:19:44` — re-enrolled via `omarchy-setup-security-fingerprint`.
- `2026-09-14 19:18:16` — `kernel: PM: suspend exit` / `usb 3-7: reset full-speed USB device`.
- `2026-09-14 19:18:18` — `quickshell[...]: pam_fprintd(omarchy-lock-fingerprint:auth): No prints enrolled`.

Both losses happened within seconds of a suspend/resume boundary. Across both boots, `usb 3-7` resets constantly (roughly matching every `PM: suspend exit` logged, i.e. many times per day) — that part is presumably normal USB re-enumeration on resume, but on this driver it appears to sometimes take the enrolled print with it.

### Ruling out "just a stuck session"
This looked at first like it could be the same class of bug as #11412 / #7229 (device stuck busy after suspend, not actual data loss). To check, I forced a full USB-level re-enumeration of the reader (unplug/replug equivalent) after the second loss:

```
echo "3-7" | sudo tee /sys/bus/usb/drivers/usb/unbind
sleep 1
echo "3-7" | sudo tee /sys/bus/usb/drivers/usb/bind
sleep 2
fprintd-list "$USER"
```

`fprintd-list` still reported no fingers enrolled after the rebind. Since this is a match-on-chip (MOC) sensor, the template should live on the chip itself and survive a mere re-enumeration if it were still there — so this looks like genuine erasure, not a transient session/driver-state issue.

### Ruled out: USB autosuspend
I initially suspected runtime USB autosuspend (the reader has `ID_AUTOSUSPEND=1` via `60-autosuspend-fingerprint-reader.hwdb`) was causing the resets and forced `power/control=on` via a custom udev rule. The reader still reset constantly and the enrollment was still erased on the very next suspend/resume cycle, so autosuspend is not the mechanism — the resets track suspend/resume, not idle timeouts.

### Relation to existing issues
This may be a more severe variant of #11412 (fingerprint stuck busy after suspend, shell retries at 4Hz with no backoff/cap) and #7229 (fprintd "Cannot run while suspended"). Those describe failure to *authenticate* after suspend; this report is about the *enrollment itself* being wiped, requiring re-enrollment via `omarchy-setup-security-fingerprint` each time. It's possible the same suspend-time retry storm described in #11412, hitting the `goodixmoc` driver's incompletely-implemented enroll-state machine, is what corrupts the on-chip print database.

### Impact
Fingerprint unlock/sudo/polkit becomes unusable again after (what appears to be) any unlucky suspend/resume cycle, requiring a full manual `fprintd-enroll` re-run. On a laptop that suspends many times a day, this recurs quickly.