Bridge still fails to recover after hibernate (stale HID handles, no resume handling) #27

Bug Description

Follow-up to #16 (closed via #23). Reported by sLimbutin in Discord: Bridge still fails to recover when waking the PC from hibernation. #23 only relaunches the process when the eframe/Glow tray loop exits — if the process survives hibernate, nothing recovers the HID state.

Repro

1. Open Bridge, connect a mouse
2. Hibernate the PC (~10 min), wake it
3. Bridge is either gone or (worse) still running but the device no longer responds; webapp/Desktop show stale controls

Root cause (code read, not yet runtime-verified)

Two gaps, both in current main:

1. No power/resume handling at all. grep -rni suspend/resume/hibernate/PBT_ /tmp/bridge/src finds nothing except UI wakers and thread::sleep. Nothing listens for WM_POWERBROADCAST / PBT_APMRESUME (Windows) or suspend/resume hooks (Linux), so after resume the runtime keeps whatever HID state it had going into hibernate.

2. Stale-handle reuse in src/hid.rs HidSession::open(). open() early-returns Ok when the key is already in open_devices without validating the handle. After hibernate, USB re-enumerates (new paths) and pre-hibernate HidDevice handles are dead, but Bridge keeps reporting open-success and every subsequent read/write fails. reconcile_inventory() only runs on list, so a connected webapp that never re-lists keeps using dead handles forever. The per-session HidApi instance is also created once (HidSession::new) and only refreshed on list.

Proposed fix

• Short term: on any HID I/O failure, do one refresh_devices() + reopen same path retry before erroring; evict the dead open_devices entry so the next open actually reopens instead of returning Ok on a dead handle. Return a typed device-gone error so the webapp re-opens.
• Proper fix: handle resume explicitly — Windows hidden window for PBT_APMSUSPEND / PBT_APMRESUME, Linux suspend/resume hook — posting a BridgeCommand::SystemResumed that refreshes enumeration, drops all open handles/readers, and pushes a fresh snapshot so the panel re-lists.
• Optional: watchdog for the alive-but-dead tray case (process up, Glow loop stalled) since Relaunch Bridge after the tray panel dies on hibernate #23 only covers loop exit.

Needed to confirm

• Bridge log around the hibernate/wake window (does the process exit + relaunch, or stay up with HID errors?)
• OS + Bridge version, wired vs 2.4 GHz
• Whether re-listing / re-opening the device in the webapp (without restarting Bridge) recovers it — distinguishes stale-handle vs dead-process