[Bug]: Windows Dynamic Lighting (Logitech LampArray service) claims the G logo LED on mice

### Pre-flight checklist

- [x] I searched [existing issues](https://github.com/AprilNEA/OpenLogi/issues?q=is%3Aissue) and this is not a duplicate.
- [x] I am on the [latest release](https://github.com/AprilNEA/OpenLogi/releases/latest) or a recent `master` build.
- [x] I quit **Logi Options+** before running OpenLogi (the two apps fight over HID++ access and only one can own a receiver at a time).

### Which part of OpenLogi?

GUI (desktop app)

### OpenLogi version

0.8.1

### Operating system

Windows

### OS version & architecture

Windows 11

### Device model

G Pro Wireless

### How is the device connected?

Logi Bolt receiver

### Affected area(s)

- [ ] Device discovery / detection
- [ ] Button remapping
- [ ] DPI control
- [ ] SmartShift
- [ ] Per-application profiles
- [ ] Battery status
- [ ] Settings / configuration (TOML)
- [ ] Auto-update
- [ ] Menu bar / tray
- [x] Other

### What happened?

Colour control only changes the battery dots, never the G logo. The logo keeps playing a blue wave. Nothing logs an error, the device ACKs every write.

Root cause (verified live on hardware): Windows' logi_lamparray_service (installed via Windows Update, logi_lamparray_usb.inf) streams a Dynamic Lighting accent-colour wave to the logo zone over HID++ every ~0.5s, clobbering OpenLogi's 0x8070 zone-1 writes. Zone 0 (dots) isn't claimed by it, so those writes stick. Caught the wave at exactly (0, 120, 212) = Windows accent #0078D4; a raw red write to zone 1 lands for one sample, then is overwritten. Turning off Settings → Personalization → Dynamic Lighting fixes it — with it off, OpenLogi controls both zones and the colour holds. (Ruled out: onboard profile lighting is empty in the dumped profile sector; setSwControl and persistent writes make no difference.)

I see two possible solutions. Either detect the LampArray bridge (VHF device, vid 046d + device wpid as pid) / the running service on Windows and warn users, or on the long-term, claim the lamps via the WinRT LampArray API so Windows actually gives ownership.

### Steps to reproduce

1. Windows 11, Dynamic Lighting on (default), Logitech mouse paired via receiver
2. Open OpenLogi, set a lighting colour
3. Battery dots take the colour; the logo keeps cycling Windows' accent-blue wave

### Diagnostics report

```markdown

```

### `openlogi list` output

```text

```

### Logs

```shell

```

### macOS permissions (if applicable)

- [ ] OpenLogi has **Accessibility** permission (needed to remap buttons via the event tap).
- [ ] OpenLogi has **Input Monitoring** permission (needed for Bluetooth-direct devices and capture).

Start by reproducing the Windows 11 Dynamic Lighting conflict with the Logitech LampArray service and inspect the HID++ 0x8070 zone-1 writes described in the report. Compare detecting the LampArray bridge or service with using the WinRT LampArray API. Done means the chosen approach prevents the service from overwriting the G logo lighting, while the battery dots and logo remain controllable.

Written by the indexing model from the issue text.