docs: UVC-H.264 detection decision tree + RØDE case study

[andrescera]

What

Add a durable engineering note, docs/notes/uvc-h264-detection.md, that answers "does this USB device have hardware H.264 over UVC?" from the device's own descriptors:

• The general four-branch decision tree: frame-based H.264/H.265 GUID → standard path (the only path this element implements); UVC H.264 XU GUID A29E7641-DE04-47E3-8B2B-F4341AFF003B + MJPEG aux → legacy XU (unimplemented by design, cross-ref camera-compat.md:20-24); other/vendor XU → needs the vendor spec; else → "no descriptor-advertised H.264 mechanism found".
• Why the USB descriptors are a complete oracle — the kernel exposes the raw device + all configuration descriptors via the descriptors sysfs attribute (drivers/usb/core/sysfs.c:853-893), readable offline without a driver.
• The RØDE HDMI-to-USB-C (19f7:0080) case study: UVC 1.0, YUY2 + MJPEG only, no Frame-Based descriptor, no Extension Unit, no vendor H.264 claim, no firmware channel → branch 4, final.
• The honest limitation: a fully hidden vendor-only mode is not establishable from descriptors alone.

Why

The "surely this capture dongle really does H.264, our probe just missed it?" question recurs per device. This note makes the descriptor-level reasoning durable and reusable so it is never re-litigated, and gives field engineers a decision tree plus a worked example. It is cross-linked from CeraUI's "Why MJPEG?" explainer and from cerastream/docs/notes/hardware-validation.md.

How to verify

Docs-only change — no code, no build/test impact. Read the note; the citations (libuvc parse sites, plugin negotiate sites, camera-compat.md:20-24, kernel sysfs) line up with the existing camera-compat.md and the RØDE descriptor evidence.

Risks

None to code. The note lives at repo-root docs/notes/ to match the public URL consumed by CeraUI and the platform; the sibling camera-compat.md cross-ref uses a within-repo relative path.