Keep session alive across transient device disappearance

[ImmortalDragonm]

Problem

After importing an .entlayout, the layout-image / .entlayout Export actions could go completely dead — clicking Export did nothing and no file dialog appeared.

Root cause

The export menu items (and other layout-gated UI) are enabled only while a keyboard is connected — self.layout.is_some(). So a dead Export button means the layout had been cleared out from under it.

A large import writes a burst of HID transactions (keymap for every layer × key, encoders, the macro buffer, combos). Under that load the board briefly re-enumerates on USB. The very next device scan sees an empty list and immediately tears the whole session down (clear_connected_keyboard_state → layout = None, selected_device = None). On Linux the follow-up scan can then hit the udev-rules guard and refuse to auto-reconnect, leaving Export greyed out until the user manually re-selects the device.

Fix

Debounce the disappearance in apply_device_scan_result:

• Require the selected device to stay absent for 3 consecutive scans (~3s) before clearing state. Within that window the device list, selection and layout are preserved untouched, so Export and other actions keep working.
• When the device reappears after a transient absence, the previously opened HID handle is stale, so force a reconnect to reopen it even when a layout is still present.

A genuine unplug still surfaces as "No device detected" after the short debounce window.

Testing

• cargo build, cargo test (59 passed).
• Change is confined to the device-scan reconciliation path; no behavior change when the device never disappears.

🤖 Generated with Claude Code

[ImmortalDragonm]

Closing: this was based on a wrong hypothesis. Reproducing the reported "menu dead after import" on real hardware showed the device does not disappear/re-enumerate during import (layout stays connected the whole time) — the actual cause is synchronous native file dialogs blocking the UI thread, fixed in #80. This debounce addresses a transient-disappearance scenario that was never actually observed, and it delays the genuine-unplug notice by ~3s, so it's not worth merging.