[Bug]: DPI writes are refused with LogitechInternal (0x2202) while the mouse is in onboard mode — 0x8100 host mode is never asserted

### Pre-flight checklist

- [x] I quit Logi Options+ / G HUB before testing — G HUB is not installed on this machine at all (no app, no launch agents, no processes, no system extensions).
- [x] I searched existing issues for my device.

### Device model

Logitech PRO X 2 (wpid `40a9`)

### Connection

Lightspeed receiver (`vid=046d pid=c54d`)

### What's the problem?

DPI never changes. The GUI reads the current DPI correctly and accepts a new value, but the device keeps the old one. The only trace is in the agent log:

```
DPI write failed error=HidppFeature { operation: WriteDpi, feature_hex: 8706, kind: LogitechInternal }
```

`openlogi diag dpi` shows it directly:

```
device: Slot 1 (slot 1 on receiver 306321A3)
current DPI: 3200
supported DPI: 100..44000 (step ≈ 1, 957 values)
writing DPI: 3220
Error: write DPI

Caused by:
HID++ feature error during WriteDpi for feature 0x2202: LogitechInternal
```

### `openlogi list` output

```text
Lightspeed Receiver (306321A3, vid=046d pid=c54d)
└─ slot 1 ● PRO X 2 (mouse, wpid=40a9, battery=90% full (discharging))
model_ids=[40a9,c09b,0000] ext=02 serial=… unit_id=902edc64 transports=usb+equad
```

### Root cause

The mouse is in **onboard mode**: its firmware is running a profile out of its own memory, owns the sensor, and rejects host DPI writes before they reach it. `0x2202` reports that as the catch-all `LogitechInternal`.

`0x8100 OnboardProfiles` is what hands the sensor back. Reading and writing it by hand over HID++ (short report, `getOnboardMode` fn 2 / `setOnboardMode` fn 1) makes the difference reproducible on demand, same device, same session:

```
onboard mode: 01 (onboard) → openlogi diag dpi → LogitechInternal
onboard mode: 02 (host) → openlogi diag dpi → ✓ DPI round-trip OK
```

The mouse exposes the feature (`openlogi diag features` lists `13 0x8100 v0`), but OpenLogi's registry knows `0x8100` by name only — there is no implementation, so host mode is never asserted.

This is also why the problem often appears **after uninstalling G HUB** rather than while it is installed: G HUB asserts host mode on every connect, so it was masking the gap. The mode is volatile by design — the device returns to onboard mode on reconnect, wake and power-cycle — so asserting it once at connect is not enough either.

### Steps to reproduce

1. Use a G-series mouse that exposes `0x8100` (PRO X 2 here), with no G HUB running.
2. Put it in onboard mode — or simply unplug/reconnect it, which the firmware does for you.
3. `openlogi diag dpi`, or change the DPI in the GUI.

### Details

- macOS 15.7.9 (24G830), arm64
- OpenLogi 0.8.3

I have a fix for this and will open a PR that implements `0x8100` and retries the refused write from host mode.

Start at the feature registry entry for HID++ feature 0x8100 and the DPI write path exercised by `openlogi diag dpi`; the issue identifies the missing OnboardProfiles implementation and the refused-write condition. Trace connection and reconnect handling to determine where host mode is asserted. Done means onboard mode is switched to host mode for supported devices and the DPI round-trip succeeds after connect or reconnect.

Written by the indexing model from the issue text.