feat(web): auto-retry transient "Cannot reach Maple API" errors

[Makisuo]

What

Makes transient connectivity failures ("Cannot reach Maple API") recover automatically instead of sticking until a manual page reload.

Why

Users frequently saw the error persist even though reloading fixed it — the failures are transient. Two gaps caused this:

1. HTTP layer failed fast on network errors. Both atom clients' HttpClient.retry predicates explicitly excluded transport errors (only 500/502/503 retried).
2. No recovery once failed. effect-atom keeps the failed result; the error UI only offered a manual "Try again" button.

How

HTTP layer — new shared retry-policy.ts used by atom-client.ts and v2-atom-client.ts:

• Transport errors retry up to 3 extra times with 300ms → 600ms → 1.2s exponential backoff.
• Idempotent methods only (GET/HEAD/OPTIONS) — transport failures can occur after a request reached the server, so mutations never replay.
• The 45s client timeout (TimeoutError) and aborted requests are excluded so a hang isn't multiplied.
• The existing 5xx retries gain the same backoff (previously immediate re-fire).

UI layer — formatBackendError now tags connectivity failures with kind: "network"; a new useNetworkAutoRetry hook (no-useEffect convention, useMountEffect + useEffectEvent) probes:

• on a jittered 5s → 10s → 20s → 30s-cap backoff (jitter decorrelates multiple error panels on one screen),
• immediately on the window online event or when the tab becomes visible again,
• pausing while the tab is hidden or the browser reports offline.

ErrorState auto-probes whenever a retry callback exists and appends "Retrying automatically…" to the copy; RouteError gets the same treatment for route-loader failures. The manual "Try again" button stays as an instant probe.

Reviewer notes

• Dashboard widget queries go over POST (/api/query-engine/execute), so they intentionally skip the HTTP-layer replay; they recover via the UI-layer probe re-running the query atom (verified working).
• InvalidUrlError keeps the same error copy but is not tagged network — a bad URL never self-heals.
• Backoff resets if a probe unmounts/remounts the error state (error → loading → error), effectively a steady ~5s poll during a long outage; the 5s floor keeps that cheap. Noted in the hook's doc comment.

Testing

• Unit: kind: "network" assertions in error-messages.test.ts; method-scoping + timeout-exclusion in retry-policy.test.ts. Full apps/web suite: 97 files / 738 tests pass. bun typecheck clean.
• End-to-end: loaded the dashboard, killed the API server mid-session — GETs retried with backoff, POSTs failed fast, error states showed "Retrying automatically…" and kept probing. Restarted the API: the entire dashboard (environments, stat cards, charts) repopulated with zero user interaction.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[pullfrog]

Your Pullfrog Router balance is exhausted.

You have a card on file but auto-reload is disabled, so runs paused once your balance went past the overdraft buffer.

Top up balance → · Enable auto-reload →

  ^{｜ ⚠️ this action is pinned to a commit SHA, which freezes the cleanup step — switch to @v0 or keep the SHA fresh with Dependabot ｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus ｜ 𝕏}