Add OpenRGB device support for PC peripheral ambient lighting

New device type enabling control of keyboards, mice, RAM, GPU, and fans
via the OpenRGB SDK server (TCP port 6742). Includes auto-discovery,
health monitoring, state snapshot/restore, and fast synchronous pixel
send with brightness scaling. Also updates TODO.md with complexity notes.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

TODO.md

@@ -7,32 +7,58 @@ Priority: `P1` quick win · `P2` moderate · `P3` large effort
 - [x] `P1` **Noise gate** — Suppress small color changes below threshold, preventing shimmer on static content
 - [x] `P1` **Color temperature filter** — Already covered by existing Color Correction filter (2000-10000K)
 - [ ] `P1` **Zone grouping** — Merge adjacent LEDs into logical groups sharing one averaged color
+  - Complexity: medium — doesn't fit the PP filter model (operates on extracted LED colors, not images); needs a new param on calibration/color-strip-source config + PixelMapper changes
+  - Impact: high — smooths out single-LED noise, visually cleaner ambilight on sparse strips
 - [x] `P2` **Palette quantization** — Force output to match a user-defined palette (preset or custom hex)
 - [x] `P2` **Drag-and-drop filter ordering** — Reorder postprocessing filter chains visually
 - [ ] `P3` **Transition effects** — Crossfade, wipe, or dissolve between sources/profiles instead of instant cut
+  - Complexity: large — requires a new transition layer concept in ProcessorManager; must blend two live streams simultaneously during switch, coordinating start/stop timing
+  - Impact: medium — polishes profile switching UX but ambient lighting rarely switches sources frequently
 
 ## Output Targets
 
 - [ ] `P1` **Rename `picture-targets` to `output-targets`** — Rename API endpoints and internal references for clarity
+  - Complexity: low — mechanical rename across routes, schemas, store, frontend fetch calls; no logic changes, but many files touched (~20+), needs care with stored JSON migration
+  - Impact: low-medium — improves API clarity for future integrations (OpenRGB, Art-Net)
 - [ ] `P2` **OpenRGB** — Control PC peripherals (keyboard, mouse, RAM, fans) as ambient targets
+  - Complexity: medium — new device type + client (OpenRGB SDK uses a TCP socket protocol); new target processor subclass; device discovery via OpenRGB server
+  - Impact: high — extends ambient lighting beyond WLED to entire PC ecosystem
 - [ ] `P2` **Art-Net / sACN (E1.31)** — Stage/theatrical lighting protocols, DMX controllers
+  - Complexity: medium — UDP-based protocols with well-documented specs; similar architecture to DDP client; needs DMX universe/channel mapping UI
+  - Impact: medium — opens stage/theatrical use case, niche but differentiating
 
 ## Automation & Integration
 
 - [ ] `P2` **Webhook/MQTT trigger** — Let external systems activate profiles without HA integration
+  - Complexity: low-medium — webhook: simple FastAPI endpoint calling SceneActivator; MQTT: add `asyncio-mqtt` dependency + subscription loop
+  - Impact: high — key integration point for home automation users without Home Assistant
 - [ ] `P2` **WebSocket event bus** — Broadcast all state changes over a single WS channel
+  - Complexity: low-medium — ProcessorManager already emits events; add a WS endpoint that fans out JSON events to connected clients
+  - Impact: medium — enables real-time dashboards, mobile apps, and third-party integrations
 - [ ] `P3` **Notification reactive** — Flash/pulse on OS notifications (optional app filter)
+  - Complexity: large — OS-level notification listener (platform-specific: Win32 `WinToast`/`pystray`, macOS `pyobjc`); needs a new "effect source" type that triggers color pulses
+  - Impact: low-medium — fun but niche; platform-dependent maintenance burden
 
 ## Multi-Display
 
 - [ ] `P2` **Investigate multimonitor support** — Research and plan support for multi-monitor setups
+  - Complexity: research — audit DXGI/MSS capture engine's display enumeration; test with 2+ monitors; identify gaps in calibration UI (per-display config)
+  - Impact: high — many users have multi-monitor setups; prerequisite for multi-display unification
 - [ ] `P3` **Multi-display unification** — Treat 2-3 monitors as single virtual display for seamless ambilight
+  - Complexity: large — virtual display abstraction stitching multiple captures; edge-matching calibration between monitors; significant UI changes
+  - Impact: high — flagship feature for multi-monitor users, but depends on investigation results
 
 ## Capture Engines
 
 - [ ] `P3` **SCRCPY capture engine** — Implement SCRCPY-based screen capture for Android devices
+  - Complexity: large — external dependency on scrcpy binary; need to manage subprocess lifecycle, parse video stream (ffmpeg/AV pipe), handle device connect/disconnect
+  - Impact: medium — enables phone screen mirroring to ambient lighting; appeals to mobile gaming use case
 - [ ] `P3` **Camera / webcam** — Border-sampling from camera feed for video calls or room-reactive lighting
+  - Complexity: medium — OpenCV `VideoCapture` is straightforward; needs new capture source type + calibration for camera field of view; FPS/resolution config
+  - Impact: low-medium — room-reactive lighting is novel but limited practical appeal
 
 ## UX
 
 - [ ] `P3` **PWA / mobile layout** — Mobile-first layout + "Add to Home Screen" manifest
+  - Complexity: medium-large — responsive CSS overhaul for all tabs; service worker for offline caching; manifest.json; touch-friendly controls (larger tap targets, swipe gestures)
+  - Impact: high — phone control is a top user request; current desktop-first layout is unusable on mobile