fix(desktop): recover when a wsl-only backend never becomes ready

[macodev00]

Problem

Fixes pingdotgg#14393

In WSL-only mode the desktop app stays on "Connecting to WSL..." until the primary backend reports ready, and that splash has no controls. If the WSL backend passes preflight and then never becomes ready — it exits on startup, or stays up but never answers — the restart loop was uncapped. The only way out was Task Manager plus editing desktop-settings.json.

Change

After three consecutive pre-ready failures, the primary asks the pool to recover. That covers both loops: a child that exits before it is ready, and a live child whose readiness budget runs out three times (the process is killed so the same exit path owns recovery). The pool shows a fixed native error and applies the existing in-memory Windows fallback, so this launch starts Windows and the next app start tries WSL again. A Windows primary has no distro and keeps the normal restart loop. Exits after a successful ready do not count.

This supersedes pingdotgg#14763. That review's blocking Medium was that a user-driven start() during teardown kept the previous startupFailureAttempt, so the replacement could fall back on its first pre-ready failure. The active-run branch of start() now clears the startup budget when it transitions from stopped to running, instead of only clearing it later on the configuration-resolve path.

Scope and approval

Accepted bug pingdotgg#14393. Triage (juliusmarminge, 2026-09-30) asked for the same in-memory Windows fallback already used for a bounded preflight failure, for both the exit loop and the live unreachable loop, without persisting the switch.

Verification

Head: 91957b54eb607f537d2089d2fb81ae6b7a29c6bf. Linux 6.12.94+ x86_64, Node v24.13.1.

./node_modules/.bin/vp test run apps/desktop/src/backend/DesktopBackendManager.test.ts apps/desktop/src/backend/DesktopBackendPool.test.ts --testTimeout 20000

Observed: Test Files 2 passed (2), Tests 34 passed (34).

The new tests check: three pre-ready exits switch to the replacement config and become ready, and a further 30s does not spawn again; a user-driven start() while the previous run is still closing gets a fresh budget, so the replacement's first exit does not recover and the third does; three readiness budgets on a live child recover as unreachable and the next process becomes ready; exits after ready do not count; the pool dialog is the fixed template (no URL, no MODULE_NOT_FOUND), in-memory settings switch to Windows, wslDistro is kept, and the Windows backend becomes ready.

./node_modules/.bin/vp lint apps/desktop/src/backend/DesktopBackendManager.ts apps/desktop/src/backend/DesktopBackendManager.test.ts apps/desktop/src/backend/DesktopBackendPool.ts apps/desktop/src/backend/DesktopBackendPool.test.ts

Observed: exit 0, no findings.

cd apps/desktop && ../../node_modules/.bin/tsc --noEmit --pretty false

Observed: exit 0 (one pre-existing, unrelated suggestion in src/app/DesktopClerk.test.ts).

Limitations: no Windows host or WSL distro was available, so this was not exercised in a live Electron session; the dialog copy is asserted in tests. With the default one-minute readiness budget, a live unreachable backend waits about three minutes before the dialog. The fallback is in memory for this launch only. A primary that already resolved to Windows keeps restarting. libatomic.so.1 and ffi-rs MODULE_NOT_FOUND are separate and not handled here.

UI Changes

None to layout or styling. The only user-visible addition is a native dialog.showErrorBox with fixed copy, the same primitive the preflight fallback already uses.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included the verification steps and observed results
• Before/after screenshots (none: no layout change; native error box copy asserted in tests, no Windows/WSL environment available)
• Video (none: no interaction changes)

Grok 4.7 via Cursor.