Add support for Philips Evnia Ambiglow (monitor built-in LEDs, ENE 6K7732 over USB)

[grigosback]

Detailed functionality path

Philips Evnia monitors (34M2C8600, 27M2N8500, 42M2N8900 and others) have built-in
"Ambiglow" LEDs around the back of the panel. They are driven by an ENE 6K7732 MCU on the
monitor's own internal USB hub, which enumerates as 0cf2:a201. Philips only ships Windows
software for it, and its effects are firmware-generated - in HDR the glow falls back to
white regardless of screen content.

The MCU is straightforward to drive. Interface 0 is vendor specific with no endpoints, so
LED colours are written with a single USB control transfer per frame:

bmRequestType=0x40, bRequest=0x80, wValue=addr>>16, wIndex=addr&0xFFFF

Writing N RGB triplets to the colour buffer at 0xC450 sets every LED; the monitor's own
engine renders that buffer. On a 34M2C8600 that is 46 LEDs.

Proposed user flow: select ambiglow under LED hardware, set the LED count to match the
panel, and configure the layout as usual. No cabling, no controller board, no extra
software - the monitor is already connected by USB.

I have a working driver and would like to contribute it. Opening this first as the PR
template asks.

• Registered as ambiglow in leds_group_3_serial (already labelled "USB/Serial")
• Lives in led-drivers/other/, which CMake globs, so no build system changes
• libusb is dlopened at runtime, not linked - the same approach ProviderSpiLibFtdi
  already uses for libftdi. No new build dependency, and it works on Windows where
  HyperHDR links ftd2xx rather than libusb. libusb-1.0 is already declared in the
  runtime package dependencies.
• Diff is 436 insertions, 0 deletions: driver .h/.cpp, a schema, one line in
  LedDeviceSchemas.qrc, four strings in en.json

Tested driving a 34M2C8600 at ~45 fps on Arch Linux (PipeWire capture of a 10-bit HDR
output) and on Windows 11. Rebased onto the v22.0.0.0 release; a full CI run on my
fork is green on all 17 targets including Windows/MSVC 2022 and both macOS architectures:
https://github.com/grigosback/HyperHDR/actions/runs/33685865585

Branch: https://github.com/grigosback/HyperHDR/tree/ambiglow-driver

The device is also WCID, advertising compatible ID WINUSB, so Windows binds winusb.sys
from the device's own descriptors - no Zadig or INF needed.

Justification

It adds support for a class of monitor that has ambient lighting built in, with no
additional hardware at all. Anyone with an Evnia panel can go from nothing to working
ambient lighting with a USB cable they already have plugged in, which is a considerably
lower barrier than an LED strip plus a controller.

It also covers a case the monitor's own firmware handles poorly: Ambiglow's built-in
"Follow Video" mode locks to white in HDR, so HyperHDR driving the LEDs directly is
strictly better on exactly the content where ambient lighting matters most.

The cost to the project is small: one self-contained driver, no build system changes, no
new dependencies, and no impact on any existing device.

I understand USB drivers inherited from Hyperion (rawhid, lightpack, paintpack) were
removed at some point - their schemas are still registered in LedDeviceSchemas.qrc but
the sources are gone. If that was a deliberate decision to stay out of USB device support,
I would rather hear it now than send a PR you do not want. Happy to maintain this one if
that helps.