[Feature]: Camera-linked light automation has no provider on Windows

### What's missing

Camera-linked light automation — the `auto_camera` setting behind the "Auto-on with
camera" toggle — has shipped since Litra support landed, but only macOS has a provider
for the fact the policy needs: is any camera in use right now.

`watchers::camera::spawn` returns an inert receiver on every other platform, so on
Windows the toggle is hidden and a Litra stays on manual power.

### Why Windows can answer this

Windows routes every camera acquisition through the Capability Access Manager, which
stamps one consent-store entry per client under

```
HKCU\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\webcam
```

That's the same bookkeeping the shell's own privacy indicator reads. A client is
holding the camera when it has a `LastUsedTimeStart` and no `LastUsedTimeStop`. It
covers packaged apps, plain Win32 executables and services alike, without OpenLogi
opening a camera itself (which would take the device away from the app using it) and
without a list of meeting applications to maintain.

### What turned up while building it

Getting this working against a real Litra Glow on Windows surfaced three defects that
are older than the feature, two of which affect macOS today:

1. **A Litra reports no serial over HID on Windows.** `HidD_GetSerialNumberString`
returns success with an empty string, so the light enumerates as `id:`,
which counts as transient — its brightness, colour temperature and `auto_camera`
never reach `config.toml`. Windows-only.
2. **HID++ capture is armed on the light's raw route.** `DeviceRoute::RawHid`'s own
doc says it "must never be passed to HID++ channel code", but `capture_plans_for`
builds a plan for any device whose physical key resolves — which a serial-bearing
light does. The gesture watcher then opens a session the light rejects and re-arms
once a second, indefinitely. Reachable on macOS today.
3. **A light is handed a value after being told to power off.**
`commands_for_light_settings` always emitted power first, so switching off sends
power-off and then, a few hundred milliseconds later, the saved brightness. A Litra
flashes on that second report. Reachable on macOS today, and on the GUI's manual
toggle as well as camera automation.

### Environment

Windows 11, `stable-x86_64-pc-windows-msvc`, Logitech Litra Glow (`046d:c900`) over USB.

I have a branch with all four parts and hardware verification, happy to open it as a PR
if the approach looks right.

Start with watchers::camera::spawn and the Windows Capability Access Manager webcam consent-store entries. Then inspect DeviceRoute::RawHid, capture_plans_for, and commands_for_light_settings to trace the three reported defects. Done means camera-linked automation works on Windows and the serial, HID++ capture, and power-setting behaviours are corrected and verified with the Litra Glow hardware.

Written by the indexing model from the issue text.