Scope WebView cookies to the request host

[mbarta]

What

Replace the manual Cookie-header plumbing in the navigation and offline/subresource HTTP paths with an OkHttp CookieJar backed by the WebView CookieManager. Same change as hotwired/turbo-android#356.

Why

Today HttpRepository and OfflineHttpRepository attach cookies by reading CookieManager.getCookie(url) for the original request URL and setting a manual Cookie header, then hand redirect-following to OkHttp using a client with no CookieJar. Because the header is set by hand rather than managed by a CookieJar, OkHttp does not re-evaluate it per hop, so it no longer tracks the actual host once a request is redirected. Set-Cookie on the final response is likewise written back against the original URL rather than the host that emitted it. The net effect is that OkHttp's cookie scoping can diverge from what the WebView itself would apply.

How

A small WebViewCookieJar : CookieJar delegates to CookieManager:

• loadForRequest(url) returns the cookies CookieManager holds for that request's host — so OkHttp attaches the right cookies for each hop, including after a redirect.
• saveFromResponse(url, cookies) writes Set-Cookie back against the host that actually emitted it.

HotwireHttpClient installs the jar; the repositories stop hand-setting the Cookie header, and OfflineHttpRepository drops any incoming Cookie header from the intercepted WebResourceRequest so the jar is the single source of cookies.

Testing

• New WebViewCookieJarTest covers host-scoped loading and saving, the OkHttp integration (request cookies, response cookies, redirect hops via MockWebServer), and the shared client wiring.
• :core:testDebugUnitTest passes.

[jeremy]

🤖 Heads up @mbarta — I've rebased #213 onto this branch, so it's now stacked on top of your per-request-host WebViewCookieJar here rather than duplicating any cookie-scoping work.

With #211 handling the cookie scoping, #213 narrows to hardening the native redirect-verification fetch on top of it:

• It disables redirect-following on the verification client, so a cross-origin redirect is detected from the Location header of the first response and the credential-bearing request is never sent on to the redirect destination at all.
• It treats "cross-origin" as a full-origin comparison (scheme + host + port), so a scheme downgrade (https → http) or a port change is correctly flagged, not just a differing host.

Net effect: the cookie-scoping fix converges here on #211, and #213 layers the verification-path hardening on top. #213's base is now host-scoped-webview-cookies, so it'll show just that delta. Thanks for the cookie jar — made the stack clean.