6ff1bff

LXManga: add on-device diagnostics (jar class, cookie names, HTTP codes)

The captcha still loops on the device after the auth row landed, and the
app produces no parser-level logging, so there is nothing in logcat to
reason from. Add a few `println` lines (logcat tag System.out) that pin
down *where* the chain breaks:

* `jar=<class>` — which CookieJar the parser got. Usagi normally binds
  AndroidCookieJar (reads android.webkit.CookieManager, so the HttpOnly
  cf_clearance written by the challenge WebView is visible); if the
  factory fell back to PreferencesCookieJar the WebView cookies are
  invisible to every plain-HTTP request and the challenge can never
  converge. This one word decides which of the two worlds we are in.
* `cookies=[...]` — the cookie *names* the jar reports for the domain
  (no values), i.e. whether cf_clearance/XSRF-TOKEN/lxmanga_session are
  actually there when the request is built.
* `-> HTTP <code>` — the response code of each catalog request, so we
  can tell "no clearance" (403) from "clearance sent but rejected" from
  "request never retried".
* getPages logs the same, plus the first 120 chars of what the WebView
  script returned.

Temporary: remove once the failure point is known.