Recover from realtime event gaps instead of silently diverging

Problem

Each WebSocket client has a 64-event buffer. When it fills, Hub.Publish silently drops events and only increments a global counter (internal/realtime/client.go:12-16, internal/realtime/hub.go:61-92). The client remains connected and receives no overflow/gap signal.

Postgres listener outages also lose events by design (internal/realtime/listener.go:32-34), but the browser socket does not reconnect when the internal listener reconnects. The current browser code refreshes the changelog only after receiving a matching event and reconnects only after its WebSocket closes (internal/server/templates/shell_scripts.html:653-691).

Impact

After a burst, slow client, or database-listener outage, a connected UI can remain stale indefinitely with no indication that it must refetch.

Acceptance criteria

• Introduce a gap/overflow recovery contract: sequence/epoch detection, an explicit resync message, or disconnect-on-overflow plus mandatory refetch on reconnect.
• Trigger resynchronization after the Postgres listener reconnects.
• Update browser consumers to refetch authoritative state on open/reconnect/gap.
• Add hub, listener, and browser-facing tests that force >64 queued events and a listener outage, then prove the client converges.