Face detection timeout uses wall-clock time, breaks after suspend/resume clock jumps

[Ludecan]

Howdy's PAM auth fails with "Failure, timeout reached" almost instantly after waking from suspend, regardless of the configured [video] timeout value in config.ini (tested with 4, 30, and 300 — all failed within ~1 second of resume).

Root cause: compare.py measures elapsed scan time using time.time() (wall-clock), not a monotonic clock:

timings["fr"] = time.time() # line 216
...
if time.time() - timings["fr"] > timeout: # line 231

On resume from suspend, some systems (like mine) experience a forward wall-clock jump (RTC drift being corrected by NTP/chrony once networking reconnects). In my case, chronyd logged Forward time jump detected! at the exact same second the USB controller finished resuming — and Howdy's timeout check, using time.time(), saw an artificially huge elapsed delta and aborted immediately, no matter how high timeout was set.

Fix: use time.monotonic() instead, which is immune to wall-clock adjustments:

- timings["fr"] = time.time()                                   # line 216
+ timings["fr"] = time.monotonic()
...
- if time.time() - timings["fr"] > timeout:                     # line 231
+ if time.monotonic() - timings["fr"] > timeout:

Applying this locally fixed facial unlock after suspend/resume for me. Happy to open a PR if useful, but flagging as an issue for now.

Environment: Pop!_OS (cosmic-greeter), Howdy built from source (master branch, sudo howdy version reports Howdy 3.0.0 BETA), Intel Raptor Lake platform with an xHCI resume quirk (USBSTS 0x411, Reinit) that also happened to trigger a chrony clock correction on every wake.

I've just checked other issues and I think it could be related to this one: #956 (comment)
There's a few more that mention "always times out" but their reasons seem to be different.