Auto-recover active sessions after signaling disconnects

[zortos293]

Description

Implement bounded automatic recovery for active sessions when signaling disconnects unexpectedly (e.g., after VPN toggle or network path changes). The renderer now attempts to reclaim and reconnect to the same session instead of immediately tearing down state.

Recovery Logic (src/renderer/src/App.tsx):

• Attempt recovery only while stream state is in live launch phases (queue, setup, starting, connecting, streaming)
• Execute up to 2 attempts with delays [0ms, 3000ms] before failing
• Prefer matching the exact sessionId; fall back to matching the tracked appId if the same session is not found
• If recovery fails, surface a user-facing launchError and reset to idle state
• If recovery succeeds, normal offer/WebRTC handling resumes

Explicit Shutdown Guard:

• Add SignalingRecoveryState ref to track recovery attempts and explicit shutdown intent
• Call markExplicitSignalingShutdown in handleStopStream and handleDismissLaunchError to prevent automatic recovery after user-initiated stops
• Reset recovery state on new game launches and navbar resume attempts

Shared Resume Helpers:

• Extract resolveSessionClaimAppId to safely resolve the appId for session claims
• Extract applyClaimedSessionAndConnect to centralize session application and signaling connection
• Refactor claimAndConnectSession to use the extracted helpers

Signaling Event Handler:

• Replace immediate teardown on disconnected events with a call to attemptSessionRecovery
• Reset recovery counters on successful offer/streaming transition

[zortos293]

@Jayian1890 if you can test this due to my sub ended so

[Copilot]

Pull request overview

Adds bounded automatic recovery in the renderer (App.tsx) to reclaim and reconnect to an existing CloudMatch session after unexpected signaling disconnects (e.g., network/VPN changes), instead of immediately tearing down stream state.

Changes:

• Introduces SignalingRecoveryState + helpers to track recovery attempts, delays, explicit shutdown intent, and appId context.
• Implements attemptSessionRecovery flow that queries active sessions, re-claims the best candidate, and reconnects signaling with a limited retry budget.
• Refactors session resume path by extracting resolveSessionClaimAppId and applyClaimedSessionAndConnect, and updates signaling event handling to use recovery on disconnected.

[Copilot]

applyClaimedSessionAndConnect unconditionally clears signalingRecoveryRef.current.explicitShutdown before connecting signaling. If the user hits Stop/Dismiss while a recovery/claim is already past the earlier explicitShutdown checks (e.g., during getActiveSessions/claimSession), this can re-enable signaling and reconnect against user intent. Consider not mutating explicitShutdown here, and instead re-check explicitShutdown (or a recovery generation/abort token) immediately before applying session state and calling connectSignaling.

[Copilot]

The disconnected handler treats any attemptSessionRecovery result of false as a hard failure and surfaces a user-facing "Session Connection Lost" error. When attemptSessionRecovery returns false because explicitShutdown was set (user-initiated stop/dismiss) or the status is non-recoverable, this can incorrectly show an error UX for an intentional shutdown. Consider explicitly checking signalingRecoveryRef.current.explicitShutdown (or returning a distinct result) and early-returning without setting launchError in that case.

[Copilot]

markExplicitSignalingShutdown clears inFlight but does not actually cancel the underlying recovery promise. If a recovery attempt is already running, it can still continue and later call applyClaimedSessionAndConnect, potentially reconnecting after a user stop/dismiss. Consider adding an abort/generation mechanism that the recovery loop (and applyClaimedSessionAndConnect) checks before updating state / reconnecting, rather than only nulling the ref.