fix(dashboard): alarm poll loop retries through faults and surfaces them; correct stale session-events empty-state copy

docs/GatewayDashboardDesign.md

@@ -252,6 +252,18 @@ dispatcher, and disposal can run on it. The two are drained concurrently, so the
 bound on disposal is 5 seconds in total rather than per loop — a wedged dispatcher
 blocks both loops at once, and draining them in sequence would time out twice.
 
+Both loops handle faults *inside* the loop and retry: only cancellation ends them.
+A failing alarm query or a render that faults on one tick leaves the page's last
+rows in place and is retried on the next tick — a fault that stopped polling for the
+life of the page would leave stale rows behind with nothing to say so. The poll loop
+also surfaces the fault in the same `Alarm query failed` banner that a query error
+uses, and clears it on the first tick that succeeds; that dispatch is itself
+best-effort, because the fault being reported may be an `InvokeAsync` against a
+disposed renderer, in which case reporting fails the same way and the loop simply
+exits on its next cancellation check. Neither loop method can fault, which is what
+the bounded drain relies on — it must never observe a faulted loop task, since that
+would surface out of `DisposeAsync` and skip the `CancellationTokenSource` dispose.
+
 ### SignalR hubs (remote clients)
 
 Updates for out-of-process clients flow over three SignalR hubs, all guarded by the