94dfc19

LXManga: re-add MangaParserAuthProvider so the captcha has a home

Two things were missing on the device:

  1. No 'Đăng nhập' row in the source settings. That row is the only
     on-demand entry point for the Cloudflare challenge, and the app
     renders it only when the parser implements MangaParserAuthProvider
     with a non-empty authUrl (SourceSettingsFragment:
     `authProvider != null && authUrl.isNotEmpty()`), so dropping the
     interface in ba30345 made the captcha reachable only by first
     tripping a 403 while browsing.

  2. The clearance obtained from the challenge was not usable by the
     plain-HTTP client, so catalog/details/tags kept failing over
     OkHttp after the captcha was solved.

Both are now handled the way the host app is actually built:

  * authUrl = https://<domain>/ — the homepage is Cloudflare-gated, so
    opening the row renders the Turnstile challenge in the app's in-app
    browser (SourceAuthActivity, which uses the parser's own
    User-Agent via getRequestHeaders()).

  * isAuthorized() = "is cf_clearance in the jar?". Usagi's cookie jar
    is AndroidCookieJar, i.e. android.webkit.CookieManager, so the
    HttpOnly cookie the browser writes is visible here even though
    document.cookie would not show it. The row is therefore disabled
    while a clearance is valid and SourceAuthActivity closes itself
    with the 'Authorized' toast once the user clears the challenge.

  * No username: getUsername() returns null, the site has no accounts.

The catalog path itself is unchanged (plain OkHttp via fetchDocument):
the app installs CloudFlareInterceptor on the HTTP client every parser
inherits, it throws CloudFlareProtectedException on a 'Just a moment…'
body, and the resolver opens the dedicated CloudFlareActivity, which
watches the same jar for a new cf_clearance and retries the request.
The manual checkResponseForProtection() + requestBrowserAction()
fallback stays for hosts without that interceptor.

Chapter error messages now point at the 'Đăng nhập' row instead of
'the source page in a webview', which is what actually fixes a stale
clearance.

Tests: 29/29 pass in the JVM harness (auth state incl. cf_clearance vs
non-CF cookie, static headers, all getPages JSON/error paths). Live
catalog is exercised by the CI runner.