fix(openlogi-hid): enumerate Bluetooth-LE-direct HID++ mice (Lift, Signature)

[7a6163]

Summary

Bluetooth-LE-direct Logitech mice (e.g. Logitech Lift, Signature series)
were never enumerated — list reported "no devices" even with the mouse
connected and working. This makes them fully controllable (inventory,
battery, DPI) without a Bolt receiver.

Root cause

Three layered issues, found by inspecting what macOS actually reports for a
BLE-connected Lift:

1. Enumeration filter too narrow. Over USB / receivers / BT-classic,
   Logitech exposes its HID++ long-report collection under usage page
   0xFF00 / 0x0002. Over BLE it uses 0xFF43 / 0x0202 instead, so the
   device was filtered out before it was ever probed.
2. Short report doesn't exist on BLE. On macOS the BLE device exposes
   only the long report (0x11) — there is no short-report (0x10)
   collection. hidpp 0.2's determine_version() hardcodes a short-report
   ping with no long fallback, so IOHIDDeviceSetReport returns
   kIOReturnNotFound.
3. (Environmental) BLE-direct mice also expose Generic-Desktop collections, so
   macOS requires Input Monitoring permission to open them — unlike a Bolt
   receiver, which is a vendor device.

Changes

• transport.rs — broaden the enumeration filter to accept both the
  USB/receiver (0xFF00/0x0002) and BLE (0xFF43/0x0202) HID++ vendor
  collections. Add a long_only channel flag (set when usage_page == 0xFF43)
  that up-converts outgoing short HID++ reports to long (0x11, zero-padded,
  same header bytes). The device answers with a long report, which hidpp
  parses and matches by header regardless of width — the same long-only
  approach Solaar uses over BLE. The receiver/USB path is byte-for-byte
  unchanged. Adds unit tests for the filter and the up-conversion.
• list.rs — refresh the "no devices" hint: BLE-direct mice need Input
  Monitoring permission; drop the stale "Bluetooth not enumerated" note.

Testing

Verified on a real Logitech Lift (BLE-direct, 046d:b031, config key 2b031):

• list — device, kind, online, battery 45% ✓
• diag features — 32 HID++ features dumped (incl. 0x2201 DPI, 0x1b04
  reprog controls; no 0x2111, so no SmartShift — expected for the Lift) ✓
• diag dpi — read 1000 → write 1200 → read-back 1200 → restore 1000 ✓
• GUI enumerates and renders the device (hotspots, DPI, battery) ✓

cargo fmt --all --check, cargo clippy --workspace -- -D warnings, and
cargo test all pass.

Follow-up (not in this PR)

This fixes HID++ control for BLE-direct mice. The device render for the
Lift (2b031) isn't in the asset registry on assets.openlogi.org yet, so
the GUI falls back to the synthetic silhouette — functional, just no photo.
Adding 2b031 to the asset host is a separate follow-up.

[pullfrog]

ℹ️ Minor suggestions only — the fix is well-scoped and the unit tests cover the new behavior.

Reviewed changes — initial review of the BLE-direct HID++ enumeration fix: a widened usage-page filter plus a long-only channel mode that up-converts short HID++ requests to long when the transport (BLE-direct on macOS) doesn't expose the short report.

• Widen the enumeration filter to two (usage_page, usage_id) pairs — 0xFF00 / 0x0002 (USB / Bolt / Unifying / BT-classic) plus 0xFF43 / 0x0202 (BLE-direct, e.g. Lift / Signature), via a constant array and an is_hidpp_long_collection helper.
• Add a long_only flag to AsyncHidChannel — set when info.usage_page == HIDPP_BLE_USAGE_PAGE. write_report re-frames short HID++ reports as zero-padded 0x11 long reports for these channels; the receiver / USB path is unchanged.
• Debug-log every Logitech HID node at enumeration time — OPENLOGI_LOG=debug surfaces vendor pages from new BLE devices without a rebuild.
• Refresh the list "no devices" hint — point at macOS Input Monitoring permission for BLE-direct mice; drop the stale "Bluetooth not enumerated" note; keep the Logi Options+ caveat and the Bolt-only hidpp 0.2 note.
• Unit tests — filter membership across USB / BLE / generic-desktop pages, plus short→long up-conversion (header preserved, payload zero-padded, non-short reports passed through).

ℹ️ Nitpicks

• The PR body has a copy/paste duplication in the transport.rs bullet — the sentence starting with "Add a long_only channel flag…" and the "long-only approach Solaar uses over BLE" sentence appear twice. Worth tidying before merge so the description matches the diff.

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

[7a6163]

Thanks for the review! Good catch — the transport.rs bullet had a copy/paste duplication in the description, now tidied. No code change; the diff is identical.

To reiterate the key safety point: the short→long up-conversion is gated strictly on the BLE vendor page (usage_page == 0xFF43), so the receiver / USB path is byte-for-byte unchanged. It's verified end-to-end on a real Logitech Lift — list, diag features (32 features), and a DPI write round-trip all succeed. Happy to address anything else.

[pullfrog]

✅ No new issues found.

Reviewed changes — re-review of the single follow-up commit since the prior pullfrog review. The new commit retires the extensibility risk I flagged in the snapshot: long_only is now derived from the HIDPP_LONG_COLLECTIONS table itself, not from a separate HIDPP_BLE_USAGE_PAGE constant.

• Folded long_only into the HIDPP_LONG_COLLECTIONS table — table is now [(u16, u16, bool); 2] with (0xff00, 0x0002, false) and (0xff43, 0x0202, true). Adding a new long-only transport is a single-row edit; the HIDPP_BLE_USAGE_PAGE constant is gone.
• Added is_long_only_collection(usage_page, usage_id) helper — used in open_hidpp_channel to derive the channel's long_only flag from the table. Returns false for pages not in HIDPP_LONG_COLLECTIONS (consistent with the filter gating opens).
• Added only_ble_collection_is_long_only unit test — asserts the BLE row is long-only, the USB / receiver row is not, and a non-matching page returns false.

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

[AprilNEA]

I did local testing, Master 3S can now connect via Bluetooth, thank you for your contribution. Of course, there are still issues with the image display, I see that #26 has resolved this problem.