Allow nested crypto for encrypted HTTP HLS while rejecting top-level protocol wrappers and local-file access. Replace the HLS-only http_persistent option with HTTP multiple_requests across probe/remux/transcode paths, fixing the raw HTTP regression introduced by #124. Add real FFmpeg regression tests and PR CI.
The /api/remux endpoint passed the user-supplied 'url' query parameter
straight to 'ffmpeg -i <url>'. spawn() with an argv array prevented shell
injection, but ffmpeg itself accepts a wide set of protocol handlers
(file://, concat:, subfile:, data:, pipe:, crypto:, async:, cache:, ...)
that read from the local filesystem or compose existing protocols.
Because the resulting ffmpeg stdout is piped directly back to the
response, an attacker who could call /api/remux could read arbitrary
local files (e.g. ?url=file:///etc/passwd, concat:file://...).
Apply two layers of defence at the entry point only:
1. validateStreamUrl(): reject anything that is not a syntactically valid
http:// or https:// URL, and reject any string containing control
characters before parsing (so CR/LF/NUL cannot be silently stripped).
2. Pass -protocol_whitelist http,https,tls,tcp,hls to ffmpeg so that even
if a future code path forwarded a different URL, ffmpeg would refuse
to open file/concat/subfile/pipe/data/crypto/async/cache inputs.
Legitimate http/https stream URLs (including ports, userinfo, queries,
and HLS playlists) continue to work; only non-network schemes and
malformed inputs are rejected with HTTP 400.
