Backfill video.streams[] per-stream breakdown (name/resolution/fps/codec)

[ch-bas]

Standing data-collection issue for the per-stream breakdown video.streams[] (name / resolution / fps / codec). Same empirical lane as low-light lux #161 and Frigate-compat #154.

The field

video.streams[] — an array describing what each encoder stream outputs, e.g.:

"streams": [
  { "name": "main", "resolution": "3840x2160", "fps": 30, "codec": "H.265" },
  { "name": "sub",  "resolution": "640x480",   "fps": 15, "codec": "H.264" }
]

This is distinct from configs.frigate.best_substream (an RTSP URL). It's what NVR / Frigate users read to pick a camera by codec + substream support.

Current coverage (of 2,618 cameras)

• 573 (22%) have any streams[] at all — 2,045 still lack it.
• Of the 573 that do, 86% have codec on every stream, so the gap is the breakdown itself, not codec within it.

How to help

From the manufacturer datasheet's Video / Compression / Stream section:

• List each stream (main / sub / third) with its max resolution, max fps, and codec.
• Codec values must be normalised (see CI issue below): H.264, H.265, H.265+, MJPEG. Not h264, M-JPEG, or H.264/H.265 (split dual-codec into the actual per-stream value).
• Leave undefined when the datasheet doesn't break streams out — never guess fps/resolution.

Good batch targets: a whole brand/series where the stream table is shared (e.g. Dahua WizSense, Hikvision AcuSense, Reolink). Rendered on the site already, so populated values show immediately.

Sibling lanes: #161 (lux), #154 (Frigate autotracking), #122 (SoC). Codec normalisation/validation is tracked separately in the CI issue.