feat(sessions): add auto-retry logic for failed connections

[jonathanlab]

Add automatic retry logic for failed agent connections that intermittently resolve on retry. The session will attempt to reconnect up to 2 times with a 10-second delay between attempts before showing an error to the user

---

Created with PostHog Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/sessions/service/service.ts:475-498
**No connectivity re-check between retry attempts**

`getIsOnline()` is evaluated once before the loop, but the loop waits 10 seconds per attempt. If the device goes offline during that gap, the retry still fires — and `clearSessionError` → `reconnectInPlace` will throw "Unable to reach server…", overwriting `lastRetryMessage` with a misleading error while consuming both retry slots. Checking `getIsOnline()` at the top of each loop iteration would short-circuit cleanly and avoid corrupting the final error message.

### Issue 2 of 3
apps/code/src/renderer/features/sessions/service/service.ts:475-506
**No tests for the retry flow — and existing test will break**

The repo rule requires comprehensive tests for retry logic covering multiple attempts. None are included. Additionally, the existing test `"creates error session when auth is missing"` (which runs with `getIsOnline()` returning `true`) now hits the retry path: `setSession` is called with `status: "connecting"` instead of `status: "error"`, and each of the two `setTimeout(resolve, 10_000)` calls runs for real since that describe block does not use `vi.useFakeTimers()`. The test will hang for ~20 s and then fail because the error state is now emitted via `updateSession`, not `setSession`.

### Issue 3 of 3
apps/code/src/renderer/features/sessions/service/service.ts:499-506
**Stale-session update after a long async gap**

Up to 20 seconds pass while the retry loop runs. In that window the user can navigate to a different task, dismiss the session, or a new `connectToTask` call can create a fresh session under the same `taskId`. The `getSessionByTaskId` lookup and subsequent `updateSession` call have no guard against this — they may stomp an unrelated session. Checking whether the current session's `taskRunId` still matches the one captured at the start of the catch block before calling `updateSession` would prevent this.

_{Reviews (1): Last reviewed commit: "feat(sessions): add auto-retry logic for..." | Re-trigger Greptile}