[Bug] Android WebView traps users on main-frame HTTP errors

Description

When the Android app loads its stored server and that server returns a non-success HTTP status for the main-frame navigation (for example, 503), the WebView renders the broken response page. With the server-switcher fallback being removed, the user has no native path back to server selection.

Expected behavior: a non-2xx response from the pinned server's main frame returns the user to the native Connect screen.

Steps to reproduce

1. Configure the Android app with a server whose main page returns HTTP 503.
2. Launch the app or navigate the main frame to that server.
3. Observe the WebView rendering the error response without a way to select another server.

Root cause

OmnigentWebViewClient did not implement onReceivedHttpError, so non-2xx main-frame responses were not surfaced to MainActivity for native recovery.

Fix

Handle all non-2xx responses only when they belong to the main frame and pinned origin, forward the status to the host, and have MainActivity launch ConnectActivity once before finishing. Subresource and off-origin responses remain untouched. Stored server state and authentication cookies are preserved.

Blast radius

Android WebView startup and navigation error recovery for the configured pinned server only. The change does not affect web, desktop, iOS, off-origin authentication, subresources, stored server state, or cookies.

Version / platform

• Baseline: production commit cb495aa49
• Platform: Android
• Authentication: not authentication-related