GHSA-g5vv-q72c-7j78

### Summary `@anephenix/hub` starts a `setInterval` polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies — which requires no authentication or special configuration — the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS). ### Details When a client connects, `loadDefaultConnectionEventListeners` (registered in `src/lib/index.ts:128`) adds a connection listener that calls `requestClientId({ ws, rpc })` for every new WebSocket (`src/lib/index.ts:262`). `requestClientId` issues an RPC send for the `get-client-id` action (`src/lib/clientId.ts:112`), which internally calls `rpc.send`. Inside `rpc.send`, the payload is pushed onto `this.requests` (`src/lib/rpc.ts:282`) and `waitForReply` is invoked. `waitForReply` starts a `setInterval` that polls `responses[]` every 10 ms for a matching reply (`src/lib/rpc.ts:250`): ```ts // src/lib/rpc.ts:250–267 interval = setInterval(() => { const response = responses.find( (r) => r.id === id && r.action === action, ); if (response) { if (interval) clearInterval(interval); // ... resolve and cleanup this.cleanupRPCCall(response); } }, 10); ``` `clearInterval` is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the `this.requests` entry. The `close` handler registered in `loadDefaultConnectionEventListeners` (`src/lib/index.ts:128–134`) only calls `pubsub.unsubscribeClientFromAllChannels`; it does not cancel pending RPC requests for that socket. **Data flow (source → sink):** 1. `src/lib/index.ts:269` — `wss.on("connection")` accepts any remote WebSocket (no authentic