G604 Lightspeed: G4-G13 buttons emit no signal at all without G-Hub's onboard-profile agent (no 0x1Bxx feature)

## Summary

The Logitech G604 Lightspeed does not expose any `0x1Bxx` reprogrammable-controls feature over the Lightspeed receiver, so `openlogi diag controls` fails and the GUI shows no button-remap panel for it. Confirmed empirically that G4–G13 (the mouse's extra buttons) produce **no OS-visible signal at all** — not even a raw HID event — unless Logitech G-Hub's background agent (`lghub_agent`) is running. This suggests these buttons only emit anything over the proprietary HID++ channel (likely gated behind the `0x8100` onboard-profiles feature that G-Hub writes/reads), which OpenLogi intentionally doesn't implement per the docs ("OpenLogi never writes a G-series onboard profile").

Filing this so the diagnostic evidence is on record, in case native G-series onboard-profile support (read-only would be enough to at least detect button presses) is ever considered.

## Device

- Logitech G604 Lightspeed Wireless Gaming Mouse
- Connected via Lightspeed receiver (not Bluetooth)
- Firmware: MainApplication `MPM21.01_B0014`, Bootloader `BL104.01_B0014`
- `openlogi list` output:
```
Lightspeed Receiver (F1C449B1, vid=046d pid=c539)
└─ slot 1 ● G604 Wireless Gaming Mouse (mouse, wpid=4085, battery=50% good (discharging))
model_ids=[b024,4085,0000] ext=00 serial=— unit_id=b0415005 transports=equad+btle
```

## What works

- `openlogi diag dpi`: full round-trip success (3500 → 3550 → restored to 3500). DPI feature `0x2201` and report-rate feature `0x2121` are both present and functional.
- Native left/right/middle click (not device-programmed, standard HID buttons).

## What doesn't work

- `openlogi diag controls`:
```
device: G604 Wireless Gaming Mouse (slot 1 on receiver F1C449B1)
Error: dump HID++ 0x1b04 reprogrammable controls

Caused by:
device does not expose HID++ feature 0x1b04
```
- Confirmed via `openlogi diag features` that no `0x1B00`–`0x1B04` feature is present in the device's 33-entry feature table at all (full dump available on request).
- Empirical test: with G-Hub's `lghub_agent`/`com.logi.ghub` launchd jobs fully unloaded and no G-Hub process running, pressing G4–G13 buttons (tested with G5 and G8, which G-Hub had macro'd to ⌘+Down / ⌘+Up) produces **no keystroke and no event at all** in a system-level HID event monitor (Karabiner-Elements' EventViewer). With G-Hub's agent running, the same buttons fire their assigned keystrokes correctly, but still produce no visible raw HID event — consistent with the agent translating a proprietary HID++ notification directly into a synthetic keypress, bypassing the standard HID input path entirely.

## Ask

Is there a known path to detect/remap G-series buttons like these without writing a full onboard profile — e.g. a read-only subscribe to whatever proprietary notification `lghub_agent` is consuming? Happy to run further diagnostics on this unit (`OPENLOGI_LOG=debug`, packet capture, etc.) if useful.

Start by reproducing `openlogi diag controls` and `openlogi diag features` for the G604, then compare HID behavior with and without G-Hub's `lghub_agent`. Use the offered `OPENLOGI_LOG=debug` diagnostics or packet capture to investigate the proprietary notification path. Done means identifying a supported read-only detection/remapping path or documenting that the device cannot be handled without onboard-profile support.

Written by the indexing model from the issue text.