Keep Remote forwarding alive through unrelated keyboard removals

[enaboapps]

Closes #1015

Problem

Remote forwarding stopped unexpectedly on Windows. Diagnostic logging showed a paired Bluetooth LE HID device ("Grid Link") dropping and reconnecting every one to two seconds. Each drop sends WM_INPUT_DEVICE_CHANGE/GIDC_REMOVAL. Capture treated that as CaptureLost, and any local capture Stopped event called remote_scan::cancel, which ended the Remote session.

Changes

• switch_input/windows_hook.rs: new State::device_removed interrupts capture only while a suppressed switch is held (Shared::has_owned), the only case where a removal can strand a key. Called from the Raw Input device-change handler in switch_input/windows.rs.
• scanning_runtime.rs: while Remote scanning is active, a local capture failure (CaptureLost, HeartbeatTimeout, QueueOverflow) resets the scanner but keeps the Remote session, so the next tick restarts Remote scanning in place. This is the same pattern as the Remote emergency-hold reset. Escape, the local emergency hold and disabling still end the session.
• Docs: docs/switches.md and docs/point-scan.md describe the new behaviour.

Validation

• npm run prediction-model, npm run lint, npm test (293 + 12 passed), npm run build
• cargo fmt --check, cargo clippy --all-targets -- -D warnings
• cargo test: 725 passed, including new tests device_removal_interrupts_only_while_a_switch_is_held and only_user_stops_end_remote_scanning
• Diagnosis was done with temporary logging (not included) on the affected machine. The logs showed repeated GIDC_REMOVAL for HID#{00001812-…}_77efbdaf2334&Col02, each followed by a CaptureLost stop.

🤖 Generated with Claude Code