fix(playback): odrzucaj nie-manifest z 200 i odswiezaj zrodlo dla 8kporner i perverzija

Sprawdzenie dwoch tubow, ktore w statystyce bledow odtwarzania wygladaly zle. Oba maja
inna przyczyne niz vjav i ZADEN nie jest awaria calego tuba.

**perverzija.** Naglowkowe "44% bledow" jest mylace: 132 ze 176 bledow pochodzi z awarii
13-18 sierpnia, ktora sama minela (te dni maja zero udanych odtworzen). Ostatnie 8 dni to
~16%. Wszystkie trzy sceny, ktore realnie padly u userow, resolwuja sie dzis poprawnie i
przechodza przez /proxy/hls jako prawidlowy manifest, wiec biezacej awarii nie ma.

Zostaje jednak realna dziura: hoster potrafi oddac 200 z trescia, ktora manifestem nie
jest (strona bledu albo reklama). Przepuszczalismy to dalej jako
`application/vnd.apple.mpegurl` ze statusem 200, a odtwarzacz konczyl komunikatem "Input
does not start with the #EXTM3U header" (203 zdarzenia w 14 dni). Gorsze od samego bledu
bylo to, ze przy statusie 200 apka uznawala odpowiedz za dobra i nie probowala odswiezyc
zrodla. Teraz w takiej sytuacji leci 502.

**8kporner.** Bledy to 502 i 400 z okcdn, rozlozone rownomiernie, przy stale dzialajacym
tubie. To zwietrzaly zapisany adres, ten sam wzorzec co watchporn. Potwierdzone na
czterech scenach, ktore padly u userow: swiezy resolve kazdej z nich oddal 206 z trescia.
Jeden przypadek w tej probce byl bledem DNS po stronie klienta, nie naszym.

Stad oba origins dopisane do `BACKEND_RERESOLVE_ORIGINS`, czyli mechanizmu juz dzialajacego
dla watchporn i galaxyporn.

Sprawdzone na prodzie po wdrozeniu: prawdziwy manifest dalej przechodzi (200, 58 kB),
a odpowiedz nie bedaca manifestem dostaje 502 zamiast 200 ze smieciami.

app/api/stream_proxy.py

@@ -761,6 +761,20 @@ async def proxy_hls_manifest(token: str, _basename: str) -> Response:
             raise HTTPException(status_code=502, detail="manifest fetch failed") from e
     if r.status_code >= 400:
         return _upstream_error_response(r.status_code, dict(r.headers), target)
+
+    # Hoster potrafi oddac 200 z trescia, ktora manifestem NIE jest (strona bledu albo
+    # reklama zamiast playlisty). Bez tej kontroli przepuszczalismy takie cos dalej jako
+    # `application/vnd.apple.mpegurl` ze statusem 200, a odtwarzacz konczyl komunikatem
+    # "Input does not start with the #EXTM3U header" (perverzija, 203 zdarzenia/14 dni).
+    # Gorsze od samego bledu bylo to, ze przy statusie 200 apka uznawala odpowiedz za
+    # dobra i nie probowala odswiezyc zrodla. Oddajemy 502, zeby wlaczyla sie normalna
+    # sciezka ponowienia.
+    if not r.text.lstrip(" \t\r\n").startswith("#EXTM3U"):
+        log.info(
+            "proxy-hls: odpowiedz 200 nie jest manifestem (%dB) dla %s", len(r.content), target
+        )
+        raise HTTPException(status_code=502, detail="upstream returned non-manifest body")
+
     rewritten = _absolutize_m3u8(r.text, base_url=str(r.url))
     return Response(
         content=rewritten,

mobile/src/screens/PlayerScreen.tsx

@@ -394,7 +394,18 @@ function NativeVideoPlayer({ params }: { params: RouteParams }) {
   // pojedynczy reset od razu spychał na WebView, który ładował zdławioną stronę tube'a
   // (stąd 502/429 w zgłoszeniu). Re-resolve otwiera świeże połączenie na tym samym URL-u,
   // co ratuje transient reset, a gate wstrzymuje WebView-fallback póki nie skończy.
-  const BACKEND_RERESOLVE_ORIGINS = ['tube:watchporn', 'tube:galaxyporncom', 'tube:naughtymachinima'];
+  // 8kporner i perverzija dopisane 2026-08-27: ten sam objaw co watchporn, czyli zapisany
+  // adres wietrzeje. Sprawdzone na scenach, ktore realnie padly u userow: stary adres dawal
+  // 502/400, a swiezy resolve tych samych czterech scen oddal 206 z trescia. Przy perverzija
+  // dochodzi manifest, ktory przestaje byc manifestem, i to teraz konczy sie 502 z proxy
+  // zamiast cichego 200, wiec ponowienie ma na czym zadzialac.
+  const BACKEND_RERESOLVE_ORIGINS = [
+    'tube:watchporn',
+    'tube:galaxyporncom',
+    'tube:naughtymachinima',
+    'tube:8kpornercom',
+    'tube:perverzijacom',
+  ];
   const canBackendReresolve =
     !!sceneId && !!params.playbackId && BACKEND_RERESOLVE_ORIGINS.includes(playOrigin ?? '');
   // Seek/decode recovery (bug f6c86847: doply/playmogo „invalid NAL length” przy