#3742 dashboard: run page polling stacks history.get and history.logs requests while serve is slow

Problem

RunDetail (packages/dashboard/src/views/RunDetail.tsx) re-reads a live run every 2.5s (LIVE_POLL_MS = 2500). usePolling uses a plain setInterval, and refetch (useRequest in client/useRequest.ts) sends a new request every tick, even while the previous one is still in flight. The request sequence only discards stale results; it does not skip or cancel the earlier request.

When serve answers slowly, the requests pile up. At the 83s history.get latency seen on swamp-serve-vm on 2026-10-21, one open run page keeps about 33 workflow.history.get + workflow.history.logs pairs in flight. A connection may have up to MAX_ACTIVE_REQUESTS = 100 (src/serve/connection.ts). Every stacked request does the full read again, which adds load to the slow server, so the slowdown feeds on itself. This matches the 239 history.get spans in 8 minutes with a single viewer reported in #3741.

Expected

A live run poll should not issue a new read while the previous one is pending. For example, schedule the next poll after the response arrives (setTimeout chained on completion), or skip a tick while a request is in flight. Optionally back off when responses are slow.

Found while

Planning #3741, which adds tracing to these reads. Its swamp.serve.active_requests attribute will show this pile-up in traces.