feat(openlogi-hid): route HID++ writes to directly-attached devices

[AprilNEA]

What & why

Today every control path assumes a device hangs off a Logi Bolt receiver at a pairing slot. Directly-attached devices (USB cable or Bluetooth) are second-class: Bluetooth ones list but are read-only, and wired ones (no battery — e.g. a corded G502) are dropped entirely. This makes them first-class.

Three blockers removed:

Before	After
probe_direct required a battery → wired mice dropped	Hybrid discriminator: keep a direct device if it reports a battery OR exposes a control feature (adjustable DPI 0x2201/0x2202 or ReprogControls 0x1b04). A receiver's secondary 0xff interface exposes neither, so the phantom-entry guard still holds.
with_device / open_target_channel bailed unless Receiver::Bolt	New DeviceRoute { Bolt { receiver_uid, slot } | Direct { vendor_id, product_id } }; open_route_channel resolves both in one place. Direct devices are addressed at HID++ self-index 0xff and re-found by vid/pid.
DpiTarget required a receiver_uid → direct devices got dpi_target = None, so DPI/SmartShift/capture were never wired up	The GUI builds a Bolt or Direct route per device; DPI, SmartShift, and gesture/button capture all route through it.

DpiTarget/GestureTarget collapse into DeviceRoute. The CLI diag commands and SharedChannel reuse follow the same route, so openlogi diag {features,dpi,smartshift} work on direct devices too.

Test plan

Run in the project devenv (real-Xcode Metal env for the GUI):

• cargo clippy --workspace --all-targets -- -D warnings → clean
• cargo fmt --check → clean
• cargo test → non-GUI 14 passed, GUI 6 passed, 0 failed
• Cargo.lock untouched; gpui pin (eb2223c0) unchanged

Still needs real-hardware verification (no G502 on hand)

• Enumeration filter (transport.rs): only Logitech VID + usage page 0xff00 / usage 0x0002 are enumerated — unchanged here. If a wired G502 exposes HID++ on a different vendor usage page (some G-series use 0xff43), it won't appear at all. This is the first thing to confirm with openlogi diag features.
• Feature discriminator: assumes HID++ 2.0 with 0x2201/0x2202/0x1b04. A variant speaking only legacy HID++ 1.0 registers would be skipped.
• Two identical direct mice on one host are indistinguishable by vid/pid (first match wins) — documented as a v0 limitation.

[pullfrog]

ℹ️ Minor suggestion only — design and refactor look solid.

Reviewed changes — initial review of the DpiTarget/GestureTarget → DeviceRoute consolidation, the new open_route_channel single-source resolver, and the hybrid peripheral discriminator that admits wired devices.

• Introduce DeviceRoute + open_route_channel — single Bolt-vs-direct resolver shared by write::with_route and gesture::run_capture_session; DpiTarget/GestureTarget removed; WriteError/GestureError collapse ReceiverNotFound into DeviceNotFound and re-key DeviceUnreachable on index rather than slot.
• Hybrid probe_direct discriminator — keep a slot-0xff device if it reports a battery OR exposes 0x2201/0x2202/0x1b04 via root feature lookup; phantom-receiver guard still holds because a Bolt secondary interface exposes neither.
• GUI plumbing — DeviceRecord::route replaces dpi_target; state/devices.rs::device_route builds Bolt or Direct from inventory (Bolt with no UID → None so writes are skipped, not mis-routed); DPI cycle / SmartShift / gesture capture all flow through the route.
• CLI diag — first_online_device returns (DeviceRoute, String); dpi / features / smartshift take &DeviceRoute.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — incremental review of the perf follow-up to the prior open_route_channel thread.

• Pre-filter Direct candidates by vid/pid before open_hidpp_channel — in crates/openlogi-hid/src/route.rs, the candidate loop now continues on a vid/pid miss for DeviceRoute::Direct before paying the ~100ms channel-open cost; the inner DeviceRoute::Direct { .. } match arm collapses to return Ok(Some(channel)) because the pre-filter already guarantees the match. Bolt branch unchanged — still opens the channel for receiver::detect and bolt.get_unique_id().

The prior review's only thread (route.rs:80-102) is addressed exactly as suggested and has been resolved.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}