De-thread the hidpp read loop without recreating the double-open hazard

The hidpp read loop runs on `std::thread::spawn`, which does not run on `wasm32-unknown-unknown`. De-threading was done and reverted inside PR #772: the thread join is what guarantees the OS handle is closed by the time `HidppChannel::drop` returns. `with_route` and `ChannelPool` defer nothing, so drop-then-reopen on the same route could leave two opens of one node alive — this tree has been bitten by exactly that (`SW_ID_LEASES` exists for it, and `RECEIVER_PROBE_BUDGET`'s doc describes the macOS "replies reach only one of two open handles" failure).

Blocked on hardware: redo this only with a Bolt receiver and a BLE-direct device at hand. Verification: enumerate both transports, DPI/SmartShift writes land, unplug/replug a receiver reopens cleanly.

Start with reverted PR #772, then trace std::thread::spawn, HidppChannel::drop, with_route, and ChannelPool. Review SW_ID_LEASES and the RECEIVER_PROBE_BUDGET documentation before testing with a Bolt receiver and BLE-direct device. Done means both transports enumerate, DPI/SmartShift writes land, and unplug/replug reopens the receiver cleanly.

Written by the indexing model from the issue text.