[codex] fix linux hook device selection

[Tinnci]

Fixes #355.

What changed

• Start the OS mouse hook only after inventory reports an online routed mouse or trackball with pointer/button capability.
• Stop the hook again when no hookable device remains or accessibility is revoked.
• Filter Linux evdev hook candidates to Logitech input devices and continue excluding OpenLogi virtual devices.

Why

On Linux the hook backend previously enumerated every evdev device with BTN_LEFT before HID++ inventory had established a target device. On laptops this can include the built-in touchpad or TrackPoint, so OpenLogi could grab those devices and create virtual mice even when there was no Logitech pointing device to manage.

Validation

• cargo fmt --all -- --check
• CARGO_TARGET_DIR=/home/drie/.cache/openlogi-target cargo clippy --workspace --all-targets -- -D warnings
• CARGO_TARGET_DIR=/home/drie/.cache/openlogi-target cargo test --workspace
• git diff --check

[recchia]

Compared this against current master. The linux.rs vendor-filter half looks superseded by #401 (merged, more thorough — also handles touchpads/pointing sticks + adds a capture_mouse_events opt-out), and would actually conflict now: linux.rs already imports crate::LOGITECH_VENDOR_ID (u32), so the local const LOGITECH_VENDOR_ID: u16 added here collides with it.

The should_install_os_hook/reconcile_hook idea in orchestrator.rs/main.rs is still genuinely useful though — master still installs the hook on accessibility_granted alone, with no check that an online mouse/trackball actually exists. Worth pulling that part into a fresh PR rebased on current master (hook_runtime::start's signature has grown since — keyboard_bindings/channel_registry/receiver_access/event_monitor), dropping the now-redundant linux.rs hunk.