SoundCloud URL handling may be an SSRF problem if the backend is exposed #173

Looking at the URL pipeline, YouTube URLs get normalized to a single-video form, but SoundCloud URLs are passed straight through to yt-dlp:

if host in _SOUNDCLOUD_HOSTS:
    return url

Allowed SoundCloud hosts include:

soundcloud.com
www.soundcloud.com
on.soundcloud.com

The shortener is the part that makes me nervous, since the app hands the URL to yt-dlp without an extractor allowlist or final URL/network target checks.

Prob low-risk when StemDeck is strictly loopback-only. But if someone runs the backend exposed on a LAN or public interface, the unauthenticated endpoints that change stuff make it easier to poke at:

• POST /api/jobs
• POST /api/jobs/{id}/cancel
• PATCH /api/jobs/{id}/sections
• DELETE /api/jobs/{id}

The Docker image itself runs uvicorn on 0.0.0.0; the sample compose binds loopback, but deployments can easily change that.

Not sure if the best fix is removing on.soundcloud.com, adding a yt-dlp extractor allowlist, rejecting redirects/final URLs outside expected hosts, adding auth/bind checks for non-loopback deployments, or some combo of those.