fix(hid): wall-clock timeout and continuation-packet validation

[AlfioEmanueleFresta]

Two HID protocol-level fixes:

• Continuation-packet validation. The HID framing parser was accepting continuation packets without checking the CID, the sequence number, or whether the high-bit-set init flag had been re-asserted. A device could splice in foreign-CID continuation frames or repeat init packets and the parser would reassemble a corrupted payload. The parser now enforces the rules from CTAP 2.2 §11.2.4: the first packet must have the init bit set, continuation packets must carry the same CID, SEQ must start at 0 and increment monotonically, and any init-bit packet during continuation is rejected. All-zero packets are also rejected outright (CID 0x00000000 is reserved).

• Wall-clock timeout. The receive loop used hidapi::read_timeout whose Ok(0) return-on-timeout was silently treated as a successful read of an all-zero report (because the report buffer was zero-initialised and the framing parser discarded all-zero packets). The CTAP2 send/recv paths additionally had no outer wall-clock timeout, so a stalled or unplugged device hung the channel until the caller dropped the future. Each read_timeout is now capped at a 100ms poll interval, the loop tracks the overall deadline and returns TransportError::Timeout once it is exhausted, and CTAPHID_CANCEL is sent on timeout in addition to caller cancellation. A new cbor_send_recv helper wraps every CTAP2 exchange in tokio::time::timeout, symmetric with send_apdu_request_wait_uv in the CTAP1 protocol module.

Notes

Why 100ms for HID_READ_POLL_INTERVAL? This bounds the latency of two things: cancel propagation when the caller's future is dropped, and wake-up after the per-op wall-clock budget expires. It does not affect end-to-end response latency: hidapi::read_timeout returns as soon as the device delivers a report. Per-syscall overhead is negligible and ~10 wakeups/sec per active channel is fine on every platform we care about. 1s would feel sluggish for cancel; 10ms would be wastefully busy. 100ms is a reasonable middle.

About the third commit / cancel-on-drop change. The previous version of this PR also contained a commit that replaced the embedded mpsc cancel channel with an AtomicBool + Notify (CancelState) shared between HidChannel and any HidChannelHandle, fixed a Drop deadlock, and propagated future-drop to in-flight reads via a CancelOnDrop RAII guard. That work is independent of the timeout fixes here (the wall-clock fix works fine on top of the existing mpsc cancel) and has been split into a separate draft PR (#208, branch fix/hid-cancel-on-drop) for cleaner review. It stacks on top of this branch.

Spec refs

• CTAP 2.2 §11.2 USB HID transport: https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#usb
• CTAP 2.2 §11.2.4 Message and packet structure
• CTAP 2.2 §11.2.9.1.5 CTAPHID_CANCEL: https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#usb-hid-cancel
• FIDO U2F HID Protocol v1.2 (older base spec): https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-hid-protocol-v1.2-ps-20170411.html

Test plan

• cargo build clean
• cargo test --lib (140 passed, 2 ignored, including 7 new parser tests)
• cargo clippy --lib --all-features -- -D warnings clean
• cargo fmt --check clean
• Manual smoke test against a real HID authenticator (MakeCredential, GetAssertion, ClientPin)
• Timeout test: unplug the device mid-transaction; verify TransportError::Timeout after the configured budget and that CTAPHID_CANCEL is logged