fix(desktop): bound boot retry loop and surface stale .env token hint on WS rejection

[andrexibiza]

What

Part of the coordinated close for #40680 (stale .env session token poisoning desktop auth). The desktop boot loop turned a 5-second failure into an hour-long lockout: Desktop boot failed: ... WebSocket (/api/ws) rejected the session token → reset requested by renderer; clearing latched failure → Restarting desktop connection → same failure, ~7+ times, with no actionable message and no bound.

This PR makes the token-rejection failure class:

1. Actionable — the failure surfaces a hint naming the exact fix: a stale HERMES_DASHBOARD_SESSION_TOKEN in the Hermes .env (resolved hermes home path) can cause this; remove the line or run hermes setup.
2. Bounded — after N consecutive token-rejection failures (N=3, consistent with the existing attempt=1/3 repair pattern), the silent loop stops and the failure is surfaced persistently through the existing boot-failure surface. Non-token failures keep their existing retry behavior.

The existing repair path is preserved — only the token-rejection class is bounded.

Dedup/composition note — overlapping open PR #74603 (authored by @Ahmett101): #74603 also edits apps/desktop/electron/main.ts, but in the probe path (regions ~1648 unwrapWindowsVenvHermesCommand, ~7599 spawnPoolBackend, ~7856 startHermes — async capability probe for #74563). This PR edits the failure-latch path (backendStartFailure latch + renderer reset handling, ~8367/8655) plus backend-start-failure.ts, which #74603 does not touch. Same file, disjoint regions — they compose, but both PRs touching main.ts means the second to merge will need a trivial rebase.

Reproduction (current vs expected)

Current (pre-fix): desktop.log shows the identical failure ~7× over an hour with no user-visible explanation:

[hermes] [boot] Desktop boot failed: Local Hermes backend is HTTP-reachable but the WebSocket (/api/ws) rejected the session token: WebSocket connection failed.
[hermes] [bootstrap] reset requested by renderer; clearing latched failure
[hermes] [boot] Restarting desktop connection

The app silently retries forever; the only remedy is manually deleting a line from a hidden .env file.

Expected (post-fix): after 3 consecutive token-rejection failures the loop stops and the failure surface names the fix — a stale HERMES_DASHBOARD_SESSION_TOKEN in the Hermes .env (resolved path) can cause this; remove the line or run hermes setup. Non-token failures keep the existing retry behavior.

How to test

cd <worktree>/apps/desktop && npx vitest run electron/backend-start-failure.test.ts

New cases: (a) token-rejection failure includes the .env hint; (b) retry counter increments per token-rejection and stops after N; (c) non-token failures keep existing retry behavior (no regression).

Platforms tested

• Windows 11 — vitest electron project, targeted file green.

Why this matters to users

Before: when desktop auth failed, the app silently retried the identical failing boot for an hour, and the user's only recourse was guessing (or being told to edit a hidden .env file with no explanation). After: the app tells you in plain words what to remove from where, and stops looping after 3 attempts so you can act instead of watching a spinner.

[andrexibiza]

Superseded by #76958 — this lane's work is consolidated into the single class-closing PR. The commit(s) live on in #76958's branch; no work is lost.