[1.0] Reconcile dashboard state after WebSocket reconnect

Some error/close sequences prevent reconnect, and opening a replacement socket does not reconcile a fresh snapshot. The dashboard can remain silently stale or miss updates.

Scope

• Make reconnect robust across supported error/close sequences and mark stale/reconnecting state visibly.
• Reconcile an authorized current snapshot with concurrent live updates without losing transitions or duplicating runs.
• Bound buffering and signal any retention/overflow gap that requires resynchronization; discard stale state on identity changes.

Acceptance criteria

• Controlled disconnect/error/close permutations reconnect and reach the same state as a fresh authorized API read.
• Updates arriving during snapshot loading are neither silently lost nor duplicated.
• An identity change cannot retain another reader's cached data; an overflow has a visible recovery path.

Boundaries

Reuse the existing WebSocket transport. A full changelog or SSE transport is not required; any adopted cursor path must enforce reader/filter/generation binding.

References

• Parent topic: #374.
• Implementation dependencies: #431, #432, #445.
• src/flock/frontend/src/services/websocket.ts
• src/flock/api/websocket.py
• src/flock/frontend/src/store/streamStore.ts

Start by reading src/flock/frontend/src/services/websocket.ts, src/flock/api/websocket.py, and src/flock/frontend/src/store/streamStore.ts, then review dependencies #431, #432, and #445. Trace reconnect, snapshot, buffering, and identity-change entry points before defining the state transitions. Done means the listed disconnect permutations recover correctly, concurrent updates are preserved without duplication, and overflow or identity changes have visible safe recovery.