Remote: resume the same session across network changes (LAN → LAN, and future off-LAN)

[Tryanks]

Summary

Remote access should survive network changes without losing the session. When the host machine and the phone move together to a different network, or later connect across networks (#376), the client should automatically reconnect to the same host and resume the same session, with no re-pairing and no lost state.

Scenarios

1. Same-network migration. Laptop and phone both leave the home LAN and join the office LAN. Both devices get new IPs. The phone should find the host again and resume the session it had at home.
2. Cross-network (future, Remote access with iroh: integration plan and feature naming #376). Laptop stays home, phone is on cellular or another LAN. Once off-LAN connectivity exists, the same recovery rules should apply: transport changes (direct ↔ relay, LAN ↔ WAN) must be transparent to the session.
3. Never-seen network. Laptop and phone arrive at a customer site or hotel for a temporary on-site assignment. Neither device has ever paired or been configured on this network. The phone should still discover the host (LAN discovery, cached host identity, or relay/routing info) and resume the same session without any manual address entry or re-pairing.
4. Mixed transitions. Phone switches Wi-Fi → cellular → office Wi-Fi while the host also changes networks. Any interleaving of these should converge back to the same session.
5. Hotspot in either direction. The phone shares a personal hotspot and the laptop joins it, or the laptop shares its connection (Internet Sharing / Mobile hotspot) and the phone joins it. Whichever device hosts the hotspot becomes the other's gateway on a private subnet that only exists while the hotspot is on (e.g. iOS 172.20.10.x, Android 192.168.43.x, macOS 192.168.2.x, Windows 192.168.137.x). Moving from a shared LAN onto a hotspot, flipping which side hosts the hotspot, or going back to a LAN must all resume the same session without manual address entry.

Expected behavior

• Session identity is bound to the host identity and pairing, not to an IP address, a single socket, or a specific network. A pairing done once at home is valid on any network the two devices later share or can reach.
• Discovery must work on networks with no prior configuration: no saved origin, no DHCP/DNS assumptions, no pre-registered addresses.
• After a transport change the client rediscovers or re-resolves the host (LAN discovery, cached addresses, relay/routing info) and reconnects automatically with backoff.
• On reconnect the client replays/resumes the existing session: open threads, in-flight streams, terminal and Preview state are recovered rather than restarted.
• The UI shows a transient "reconnecting" state and clears it on recovery. Re-pairing is only required when the pairing itself is invalid.

Current behavior

Reconnect/replay exists for a fixed origin, but a changed host address or a mid-session network switch on both ends is not recovered automatically; the user has to reselect the host or re-pair.

Notes

• Should build on the unified host entry and existing reconnect/replay from Prepare unified native remote establishment and trusted stream admission #384, and be transport-agnostic so the iroh integration in Remote access with iroh: integration plan and feature naming #376 gets it for free.
• Discovery should prefer LAN when both devices share a network, falling back to relay/WAN only when needed.
• Hotspot networks need extra care: the hosting side's interface may only come up after the first client joins, both sides change IP at the same moment, and some Android/iOS hotspots do not forward mDNS/multicast to clients. When on a hotspot subnet the client should also probe the default gateway (which is the hotspot host) and the last-known peer addresses directly, and the host should re-advertise/listen when its interface set changes rather than only at startup.