#125 [High] Add WebSocket heartbeat/keepalive and dead-connection cleanup to `IntentsGateway`

[james2177]

Description: src/intents/intents.gateway.ts manages WS connections for the public, read-only intent feed (already extended by issues #47/#48/#49/#79/#96 for topic filtering, replay, connection caps, presence tracking, and auth), but has no ping/pong heartbeat mechanism — dead or half-open connections (client crashed, network dropped without a clean close frame) are never detected or cleaned up, silently consuming a slot against the wsMaxConnections cap enforced by issue #49.

Problem Statement & Context: Without heartbeat-based dead-connection detection, a server behind a load balancer or NAT that silently drops idle connections will accumulate "zombie" entries in IntentsGateway's connection tracking indefinitely, which directly undermines issue #49's connection-cap enforcement (the cap fills up with dead connections, blocking legitimate new ones) and pollutes issue #79's WS presence-tracking stats with stale entries.

Scope & Acceptance Criteria:

• Implement a periodic ping/pong heartbeat: server sends a ping frame (or app-level { type: "ping" } message, matching whatever message-handling convention issues Audit path-parameter values for safe inclusion in error messages #47/Change the CORS_ORIGIN default away from wildcard for production use #48/Instrument the sweeper with duration and expired-count metrics #96 already established) on an interval, and closes/cleans up any connection that fails to respond within a bounded timeout.
• Ensure cleanup correctly decrements whatever connection-count tracking issue Add connection auth/allowlist to the WebSocket gateway #49's cap enforcement relies on, and removes the connection from issue Add topic-based subscriptions to the WebSocket gateway #79's presence tracking.
• Out of scope: client-side heartbeat handling in scripts/solver-bot.ts beyond whatever minimal response is needed to prove the mechanism works end-to-end — the reference bot already exists per issue Instrument the sweeper with duration and expired-count metrics #96's context and should only need to respond to pings, not initiate them.
• Out of scope: changing the fundamentally public/read-only nature of the feed — this issue is connection-lifecycle hygiene only, not a new authorization mechanism.

Implementation Guidelines:

1. Key files: src/intents/intents.gateway.ts, src/intents/intents.gateway.spec.ts, scripts/solver-bot.ts (verify/adjust its response to the new ping mechanism if needed).
2. Reuse the existing incoming-message-handling entry point (per the same reuse guidance issue Instrument the sweeper with duration and expired-count metrics #96 already follows) rather than adding a parallel message listener.
3. Choose and document explicit interval/timeout values (e.g. ping every 30s, terminate after 2 missed responses) — bound them conservatively enough to tolerate normal network jitter without prematurely dropping healthy connections.
4. Testing: extend intents.gateway.spec.ts with cases for a healthy connection surviving multiple heartbeat cycles, a non-responding connection being cleaned up within the expected timeout, and correct decrement of connection-count/presence tracking on cleanup; minimum 85% coverage on the new heartbeat logic.

Definition of Done:

• Heartbeat mechanism implemented, dead-connection cleanup verified against connection-cap and presence tracking.
• Acceptance criteria met.
• PR passes CI with test output.
• Reviewed and approved.

Resources: src/intents/intents.gateway.ts, src/intents/intents.gateway.spec.ts, scripts/solver-bot.ts

Complexity: High (200 points)