fix(web): connection health poll silently erased the escalated "down" state

useLiveStream's health-poll effect (every 10s) unconditionally reset
attemptsRef to 0 and overwrote `connection` on every successful
GET /api/health — regardless of whether the actual EventSource was open.
Since a plain health check answering says nothing about the SSE stream
itself, this meant that a few seconds after the UI escalated to "down"
(after 3 consecutive stream failures), the next poll tick would silently
flip it back to "reconnecting" and reset the reconnect backoff to its
fastest delay — so a user watching the connection badge would almost never
actually see "down", losing the signal exactly when the stream had been
failing repeatedly.

Also fixed connect() itself, which set connection to 'reconnecting' on
every dispatched retry attempt without checking whether attempts had
already crossed the DOWN_AFTER_ATTEMPTS threshold — the same downgrade bug
via a different path.

Now the poll only promotes state (and resets backoff) when the EventSource
is genuinely OPEN; otherwise it leaves the EventSource's own onerror/onopen
handlers as the sole source of truth for connection state.

Caught by web/src/hooks/useLiveStream.test.tsx ("escalates to down after
repeated failures and resumes from the last seq"), which was failing on
main before this change.

Author: piotrlaczkowski

web/src/hooks/useLiveStream.ts

@@ -160,7 +160,18 @@ export function useLiveStream(opts: StreamOptions = {}): LiveStream {
     const es = createEventSource(lastSeqRef.current);
     esRef.current = es;
     if (mountedRef.current) {
-      setConnection(attemptsRef.current > 0 ? 'reconnecting' : 'connecting');
+      // Once escalated to 'down', a dispatched retry must not silently
+      // downgrade the banner back to 'reconnecting' — the user would lose
+      // the severity signal on every subsequent attempt, right when it
+      // matters most. 'down' only clears on an actual successful connection
+      // (the 'connected'/onopen handlers reset attemptsRef to 0 below).
+      setConnection(
+        attemptsRef.current >= DOWN_AFTER_ATTEMPTS
+          ? 'down'
+          : attemptsRef.current > 0
+            ? 'reconnecting'
+            : 'connecting',
+      );
     }
 
     es.addEventListener('connected', () => {
@@ -314,10 +325,19 @@ export function useLiveStream(opts: StreamOptions = {}): LiveStream {
       try {
         const h = await getHealth();
         if (cancelled || !mountedRef.current) return;
-        attemptsRef.current = 0;
         const es = esRef.current;
-        // EventSource.OPEN === 1; CONNECTING === 0.
-        setConnection(es && es.readyState === 1 ? 'live' : 'reconnecting');
+        // EventSource.OPEN === 1; CONNECTING === 0. A successful health
+        // check only means the plain HTTP API answered — it says nothing
+        // about the SSE connection itself. Only promote state (and reset
+        // the backoff) when the EventSource is genuinely open; otherwise
+        // leave connection/attemptsRef alone so the escalated 'down' state
+        // from repeated onerror failures survives until the stream
+        // actually reconnects, instead of flapping back to 'reconnecting'
+        // (and resetting backoff to its fastest delay) on every poll tick.
+        if (es && es.readyState === 1) {
+          attemptsRef.current = 0;
+          setConnection('live');
+        }
         if (typeof h.running === 'boolean' && h.running !== runningRef.current) {
           setRunning(h.running);
         }