fd7d16c

LXManga: drop lxmanga.xyz (522) + trigger requestBrowserAction on CF

Two things broke the user-facing flow of the previous commit:

1. lxmanga.xyz (the only domain in the fallback slot) was 522 from
   the sandbox. As soon as the app's catalog probe on .space 403'd
   on Cloudflare's 'Just a moment...' page, the host-fallback logic
   the user runs in the reader silently flipped the saved setting
   from .space to .xyz and the parser never recovered. Drop .xyz
   entirely so the user stays on the only working host.

2. Even on lxmanga.space, the very first catalog request hits the
   'Under Attack' Cloudflare challenge, so OkHttp got 403 'Just a
   moment...' and there was no path forward. Now every catalog GET
   goes through a fetchDocument() helper that runs
   CloudFlareHelper.checkResponseForProtection on the response and
   hands the URL to context.requestBrowserAction() if the page is a
   challenge — same pattern CuuTruyenParser uses for the same CF
   front. After the user clears the challenge in the custom tab the
   OkHttp jar ends up with cf_clearance and the rest of the parser
   works without further interaction. MangaParserAuthProvider.authUrl
   is kept as a safety net for the WebView path (PAGES_SCRIPT's
   same-origin fetch needs cf_clearance in the WebView's
   CookieManager too).

The fetchDocument helper also covers getDetails() and the tag
listing (the previous loadAvailableTags), so the CF guard is
applied uniformly. The KDoc at the top of the class is rewritten
to call this out and to explain why cf_clearance is HttpOnly and
therefore cannot be read from WebView.document.cookie to copy into
OkHttp the way Hv2tComics does for the age-gate cookie.