stream: quality is hardcoded, no way to adapt bitrate to network capacity

Problem

Stream quality (640x360, 10 fps, 700k) is effectively hardcoded. When the uplink can't sustain the bitrate, SRT drops late packets and the viewer gets artifacts or freezes. There is no graceful degradation and no way to configure a lighter profile for sites on weak 4G links.

Two related findings:

1. Latent config bug: start_stream reads width, height, fps, conf from STREAMS[camera_ip] (routes_stream.py:77-80), but STREAMS is built in config.py with only input_url and output_url. These keys can never be set, so the defaults always apply. Per-camera quality config silently doesn't exist.
2. SRT latency unit: ffmpeg's latency option is in microseconds, so SRT_LATENCY = 50 means 50 µs (rounded to 0, libsrt falls back to its 120 ms default). The intended value was presumably 50 ms, which would be too low anyway for 4G links (rule of thumb: 3-4x RTT).

Proposal

• Propagate quality keys (width, height, fps, bitrate) from credentials.json into STREAMS so per-camera profiles work.
• Accept optional quality overrides on POST /stream/start_stream (e.g. bitrate, fps, or a profile=low|high shortcut) so the platform can pick per session.
• Fix SRT_LATENCY to an explicit microsecond value (~300000).
• Optional follow-up: switch restream mode to -c:v copy (camera already outputs H.264, re-encoding wastes Pi CPU) and control bitrate at the source via the camera API.

Out of scope: automatic ABR (HLS ladder or congestion-based encoder restart). Can be discussed later if static profiles prove insufficient.

Start in routes_stream.py around lines 77-80 and compare the expected quality keys with STREAMS construction in config.py and the credentials.json flow. Trace POST /stream/start_stream and the SRT latency setting, then verify that per-camera and request-level quality profiles are propagated and that the configured latency uses microseconds without implementing automatic ABR.