perf(poll): adaptive back-off when the backend responds slowly

[tdody]

Summary

A safety net for responsiveness under load: when /api/state is slow, the dashboard now automatically widens its poll cadence instead of stacking requests onto a struggling backend.

The dashboard polls /api/state every 500 ms while a terminal modal is open. If the backend is slow to answer (e.g. the host is swapping, or pre-#118 when collect_state forked a tmux subprocess per window), those polls pile up and contend with the keystroke round-trip that shares the backend — which is what makes typing lag. Backing off lets the backend recover.

How

• usePolling now measures each poll's wall-clock latency (EWMA) and counts superseded polls — ones aborted by the next tick before they completed. The supersede count is the signal the EWMA alone can't see: when latency exceeds the poll interval, fetches never finish to be measured, so "we keep aborting in-flight polls" is what tells us we're outpacing the backend.
• A pure nextDegraded(current, ewmaMs, supersedes) applies hysteresis — enter degraded when smoothed latency > 800 ms or ≥ 2 consecutive supersedes; exit only when latency is clearly low and polls are completing again (no flapping).
• usePolling exposes a degraded flag; pickPollInterval(..., degraded) floors the cadence at DEGRADED_POLL_MS (5 s) when degraded — overriding the modal/active/input tiers, but never lowering an already-slower interval.
• Latency state lives in refs so it survives the effect re-run when the interval changes (backing off mustn't reset the signal that triggered it).

With #118 (batched collect_state, ~30 ms /api/state) this never trips in the common case — it only engages when the backend is genuinely degraded.

Tests (TDD)

• Pure policy (pollTier): updateLatencyEwma seeding/smoothing; nextDegraded hysteresis + supersede escalation + null-sample handling; pickPollInterval degraded floor (overrides modal/input, never lowers a slower interval, no-op when not degraded). 22 tests.
• usePolling: flags degraded on high latency; stays clear on fast responses; flags degraded after repeated supersedes. Watched each fail (no degraded), then pass.
• Full frontend suite: 611 passing; tsc + vite build clean.

Notes

• Frontend-only; backend untouched. Complements perf(state): batch tmux metadata in collect_state — ~13× faster /api/state #118 (the actual /api/state speedup) — this is the resilience layer on top.

🤖 Generated with Claude Code