Sweep/vgdeband: cap x264 at ENCODE_THREADS (2) so conversions stop starving Jellyfin and the live portal

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

README.md

@@ -408,8 +408,9 @@ Where the time comes from, best first:
    start and the sidecar records drift over the file. **Then the band is cropped off**: the sweep re-encodes the
    stream (libx264 CRF 18, frame timing preserved, audio copied) so the published file is the game image + audio +
    the `tmcd` track and nothing else; the raw with the band is deleted (`KEEP_RAW_STREAMS=1` keeps it in `.src/`).
-   Streams without the band are remuxed losslessly. Cost: a 3 h 1440p60 night is a few hours of CPU on the
-   E-2136; the sweep is niced. OBS: dock → *Timecode band* →
+   Streams without the band are remuxed losslessly. Cost: every re-encode (streams and clips) runs x264 on
+   `ENCODE_THREADS` threads (2, set in `systemd/normalize-sweep.service`) so Jellyfin and live viewers stay
+   responsive; a 3 h 1440p60 night therefore takes most of the next day to publish. OBS: dock → *Timecode band* →
    "Add band + clock source" (canvas grows by W/160 rows, a locked browser source `Vanguard Clock` →
    `https://live.BASE/dock/clock/` sits in the band; only while not streaming). Go Live: the "Timecode band" checkbox (default on).
 2. **Server arrival time** (no band) — microseconds in the recording filename. Within ~0.1–0.3 s per streamer