[Feature]: Support multiple connection routes with automatic fallback and manual pinning

Before submitting

• I searched existing issues and found the related #5233.
• I am describing a concrete use case.

Area

packages/client-runtime connection handling, with settings UI support on web, desktop, and mobile.

Problem

I use the same T3 Code computer from different networks:

• At home, the LAN endpoint is the fastest option.
• Away from home, the LAN endpoint is unreachable.
• T3 Connect / Relay works from almost anywhere, but can be slow for bandwidth-heavy sessions.
• I also have an FRP HTTPS endpoint, but using it at home unnecessarily consumes my home's upload bandwidth.

A saved environment currently supports only one connection endpoint. Pairing the same computer through another URL replaces the existing connection because the catalog is keyed by environmentId.

As a result, I have to edit the saved URL manually whenever my network changes.

This is closely related to #5233, but the desired behavior also includes T3 Connect / Relay and a manual route lock.

Proposed behavior

Allow one logical environment to store multiple connection routes, for example:

• Home LAN
• Tailscale
• FRP
• T3 Connect Relay

The environment must remain a single environment with one environmentId. Routes are alternative transports for that environment, not separate environments.

The client should provide two modes:

Automatic mode

• Store an ordered route preference.
• Try the last successful route first, then fall back through the remaining routes.
• On connection or reconnect, advance to the next route after transient network failures, timeouts, endpoint-unavailable errors, or transport failures.
• Do not fall back after authentication, permission, configuration, or environment-identity errors.
• Confirm that every endpoint resolves to the expected environmentId before using it.
• Remember the route that eventually succeeds and prefer it on the next connection.
• Preserve the existing environment, threads, projections, and cached state while changing only the transport route.
• Avoid parallel racing; serial attempts with bounded per-route timeouts are sufficient.

Manual mode

• Let the user pin one specific route.
• Use only the pinned route.
• Do not silently switch to another route when the pinned route is unavailable.
• Make it easy to return to automatic mode.

Route management

On web, desktop, and mobile, users should be able to:

• Add, edit, remove, label, and reorder routes.
• Add direct HTTP/HTTPS endpoints such as LAN, Tailscale, and FRP.
• Add the linked T3 Connect / Relay route for the same environment.
• See which route is currently active and why another route was selected.
• Switch between automatic mode and a pinned route without creating duplicate environments.

Relay authentication and its existing Cloudflare Tunnel data path should remain unchanged. Relay should be another selectable route for the same environment.

Acceptance criteria

• A user can save LAN, FRP, and T3 Connect routes under one environment.
• Automatic mode works when moving between home and public networks without editing the environment URL.
• Manual mode remains stable and never changes routes unexpectedly.
• Existing single-endpoint environments migrate to a one-route configuration.
• Reconnecting after a route change does not create duplicate environments or lose thread state.
• The feature works consistently on web, desktop, and mobile.

Start in packages/client-runtime connection handling, then trace the settings UI implementations for web, desktop, and mobile. Map how environments are keyed and how existing Relay authentication and Cloudflare Tunnel data flow work before designing route storage and selection. Done means multiple routes, automatic fallback, manual pinning, migration of single-endpoint environments, and preserved state work consistently across all platforms.