fix(desktop): raise remote liveness probe timeout from 2.5s to 10s

[GratefulDave]

Summary

Fixes the connect → immediately-stale → reconnect loop reported in #49787 for remote backends reached via high-latency paths (Tailscale relay, cross-region VPN).

Root cause

hermes:connection:revalidate probes /api/status with a hardcoded 2_500ms timeout:

// main.cjs:5309 (before)
await fetchPublicJson(`${base}/api/status`, { timeoutMs: 2_500 })

This fires on every sleep/wake (onPowerResume), network online event, and visibilitychange. On a Tailscale-connected remote, relay latency can intermittently exceed 2.5s — causing the probe to time out and drop the cached connection as stale even when the backend is perfectly healthy. The result is an infinite loop:

Remote Hermes backend is ready
→ Cached remote Hermes backend failed liveness probe; dropping stale connection.
→ startHermes() rebuilds from scratch (boot progress overlay reappears at ~24%)
→ next wake/focus event fires revalidateConnection() again
→ same 2.5s race → drop again → loop

This is distinct from the bootstrap marker issue also reported in #49787 (setup screen on every launch), which has a separate fix.

Fix

Raise the revalidate timeout to 10_000ms, matching the timeout already used for the connection test (fetchPublicJson at line 4437):

// main.cjs:5309 (after)
await fetchPublicJson(`${base}/api/status`, { timeoutMs: 10_000 })

A genuinely dead backend still fails within 10s. A live backend over a high-latency relay no longer gets false-evicted.

Verification

• Affected setup: Mac M5, macOS Tahoe 26.5.1, Hermes Desktop v0.17.0, remote backend on Mac mini via Tailscale tunnel
• Tailscale round-trip: ~223ms average with occasional spikes above 2.5s
• GET /api/status returns HTTP 200 with valid JSON when probed directly; Let's Encrypt cert, no TLS issues
• With timeoutMs: 2_500: desktop.log shows repeated Cached remote Hermes backend failed liveness probe within seconds of each Remote Hermes backend is ready — confirmed via 8–10 loop iterations per session
• With timeoutMs: 10_000: probe succeeds reliably; loop stops

Related

• Closes Desktop app: reinstall/setup prompt on every launch despite valid config #49787
• Related: [Bug]: Desktop install loop on macOS — launcher uses system python3 (3.9) instead of bundled venv, hermes_cli import fails, gateway never starts #43913 (different symptom, same desktop boot area — local mode Python 3.9 detection loop)
• Related: PR fix(desktop): trust bundled venv install without marker (#43913) #43983 (missing bootstrap marker → setup screen; complements this fix)

[teknium1]

Thanks for isolating the remote liveness failure mode. The current implementation still has the reported behavior: apps/desktop/electron/main.ts:7405 probes /api/status with timeoutMs: 2_500, and its catch resets the remote connection at apps/desktop/electron/main.ts:7408-7415.

Problems

• The diff modifies apps/desktop/electron/main.cjs, but current main renamed that file to apps/desktop/electron/main.ts in 39d09453f95e8aefc0c97e5d9b30ff341cae9ed8. The live handler is therefore unchanged by this PR as submitted.
• There is no focused regression test for hermes:connection:revalidate; repository searches find the production handler and stale-probe log, but no corresponding test.

Suggested changes

• Apply the 10_000 timeout at apps/desktop/electron/main.ts:7405.
• Add a focused test for a delayed-but-successful remote status probe and for a genuinely failed probe resetting the cached remote connection.

Automated hermes-sweeper review.

[teknium1]

Current main renamed this source file to apps/desktop/electron/main.ts in 39d09453f95e8aefc0c97e5d9b30ff341cae9ed8; the live handler is now at main.ts:7405 and still uses 2_500. Port this change to that handler so the fix reaches current main.