fix(http-proxy): preserve m3u redirect semantics

[stackia]

Summary

• restrict M3U response body rewriting to successful 2xx responses
• preserve normal HTTP redirect handling for M3U and M3U8 request paths
• add an end-to-end regression test covering a 302 M3U8 response with an HTML body

Root cause

M3U detection by URL extension ran for every response status. A 302 response from a path ending in .m3u8 therefore entered the playlist body rewrite path, which bypassed the existing Location header rewrite and treated the redirect body as playlist content. Clients could then be redirected directly to an IPTV-only upstream address that they could not access.

Impact

Redirects and error responses from M3U endpoints now retain normal HTTP semantics. Successful playlist responses continue to be decoded and rewritten as before.

Validation

• Release CMake build
• pnpm run lint:clang
• uv run ruff check e2e
• ./scripts/run-e2e.sh -p 1 test_http_proxy_m3u_rewrite.py — 52 passed
• ./scripts/run-e2e.sh -p 1 test_http_proxy.py — 19 passed
• ./scripts/run-e2e.sh -p 1 test_url_template_m3u.py — 19 passed
• uv run pytest e2e --collect-only -q — 540 tests collected
• ./scripts/run-e2e.sh --co — 540 tests collected
• git diff --check

[github-actions]

Documentation preview

The documentation preview has been deployed for this pull request.

• Preview: https://thankful-water-0a297bf00-681.eastasia.1.azurestaticapps.net
• Commit: 3382f81