Trey T
d122c95342
Two follow-ups to the WebView-routing commit after user reported "Could not get any token HTTP -1": 1. WKWebView's default UA is "Mozilla/5.0 (iPhone; ...) Mobile/15E148" — missing the "Version/17.5 Safari/604.1" suffix real Safari sends. Cloudflare and other bot filters use that suffix to ID true Safari. Now we explicitly set a complete Safari UA on the WebView before navigating to route-explorer. 2. WebViewFetcher returns its errors as "HTTP <code>: <body>" strings; we were always throwing tokenFetchFailed(status: -1) regardless. New extractStatus helper parses the real upstream HTTP code out of the error string so the thrown error reflects what the server actually said — "HTTP 403" instead of "HTTP -1" makes it diagnosable from the device. If the deployed app still 403s after this, the issue is more than UA (probably Cloudflare clearance cookie needed via interactive challenge) and we'd have to consider ASWebAuthenticationSession or fall back to a paid schedule API. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>