Reacquire USB device on resume

[sillymotives]

Summary

Reacquire the fingerprint USB device before rebuilding python-validity state during Resume().

On systems where ACPI S4 powers down or resets the USB root hub, the sensor may re-enumerate at a new USB address. The existing Resume() path resets TLS and calls init.open_common(), which assumes the old PyUSB device handle is still usable. That leaves the backend registered, but operations fail with:

usb.core.USBError: [Errno 19] No such device

This change:

• records the opened sensor's VID/PID, USB bus, and physical port topology;
• reacquires the same physical reader on resume before rebuilding TLS and sensor state;
• preserves normal VID/PID discovery when physical topology is unavailable;
• keeps explicit --devpath selection strict and fails closed rather than drifting to another identical reader.

Reproduction

Reproduced on an HP EliteBook x360 1030 G2 with a Validity fingerprint sensor during real ACPI S4 hibernation.

During resume, the USB root hub loses power/reset state and the fingerprint reader re-enumerates. Before the fix, the long-running python-validity process retains the stale pre-hibernate PyUSB handle.

Restarting only python3-validity.service recovered the device, which isolated the failure to USB handle reacquisition rather than open-fprintd itself.

Hardware validation

An equivalent implementation based on python-validity 0.14 was tested end-to-end on the affected hardware.

Observed results:

• genuine S4 resume confirmed by preserved boot ID;
• the python-validity PID remained unchanged;
• the USB reader re-enumerated after resume;
• open-fprintd-resume.service completed successfully;
• python-validity reopened the sensor and restored calibration/database state;
• existing enrolled templates remained visible;
• fingerprint verification succeeded after resume.

The original stale-handle ENODEV failure did not recur.

Forward-port validation

This branch is a clean forward-port onto current 0.15 master.

It was additionally validated with focused tests covering:

• reacquiring the same physical reader after its USB address changes;
• refusing a different identical reader when the original topology was known;
• preserving strict explicit-device selection;
• falling back to VID/PID only for normal discovery when topology information is unavailable;
• failing rather than guessing when explicit selection has no usable topology.

The modified Python files compile successfully and git diff --check passes.

Scope

Only three files are changed:

dbus_service/dbus-service
validitysensor/init.py
validitysensor/usb.py

No packaging changes or device-ID additions are included.