Bug: Dashboard UI WebSocket connection flooding event loop

Summary

The Dashboard WebSocket connection (859bdebc…11f6) is repeatedly hammering sessions.list (each call taking 8–21s) and chat.history constantly. This is the single biggest event loop consumer.

Impact

• sessions.list calls taking 8–21s each block the event loop
• Constant chat.history polling compounds the load
• Degrades overall gateway responsiveness and throughput

Expected Behavior

• The Dashboard UI should throttle or debounce sessions.list and chat.history calls
• WebSocket should not poll aggressively when no visible state change is expected
• sessions.list performance should be investigated — 8–21s for a list call suggests an unbounded or expensive query path

Reproduction

1. Open the Control UI Dashboard
2. Observe WebSocket traffic and event loop profiling
3. Note repeated sessions.list calls with 8–21s duration and continuous chat.history fetches

Suggested Fixes

• Throttle/debounce: Add a minimum interval between sessions.list / chat.history WS requests from the Dashboard
• Incremental updates: Switch from full-list polling to incremental/delta updates (only send what changed)
• Backend query optimization: Investigate why sessions.list takes 8–21s — likely needs pagination, caching, or query optimization
• Conditional fetching: Only request chat.history when the user actively views a session, not on every WS tick

Environment

• Observed on Dashboard WebSocket connection 859bdebc…11f6
• sessions.list response times: 8–21s per call