Handle ping failures in keepalive timer

The keepalive interval calls ws.ping() without guarding for sockets that have already transitioned out of OPEN, and clearKeepalive() in close/error cannot prevent a timer callback that was already queued from running. In that race (for example, close and interval firing in the same loop tick), ws.ping() can throw synchronously and bubble as an uncaught exception, which can terminate the monitor process instead of triggering normal reconnect handling.

Useful? React with 👍 / 👎.

Stale pongTimeout reference if interval fires before clearing

On each interval tick, pongTimeout is overwritten without first calling clearTimeout on the previous value. In the current setup PING_INTERVAL_MS (30s) > PONG_TIMEOUT_MS (10s), so the previous timeout always fires (or gets cleared by the "pong" handler) before the next interval tick — meaning the overwrite is safe today. However, this is a fragile invariant: if the constants were ever adjusted so that PING_INTERVAL_MS ≤ PONG_TIMEOUT_MS, the previous active timeout would be silently leaked, and two ws.terminate() calls could race. Additionally, after the timeout fires it doesn't reset pongTimeout = undefined, so clearKeepalive() ends up calling clearTimeout on an already-dead timer (harmless, but the !== undefined guard becomes unreliable).

A more robust pattern that is immune to constant changes:

This is a comment left during a code review.
Path: extensions/mattermost/src/mattermost/monitor-websocket.ts
Line: 163-169

Comment:
**Stale `pongTimeout` reference if interval fires before clearing**

On each interval tick, `pongTimeout` is overwritten without first calling `clearTimeout` on the previous value. In the current setup `PING_INTERVAL_MS (30s) > PONG_TIMEOUT_MS (10s)`, so the previous timeout always fires (or gets cleared by the "pong" handler) before the next interval tick — meaning the overwrite is safe today. However, this is a fragile invariant: if the constants were ever adjusted so that `PING_INTERVAL_MS ≤ PONG_TIMEOUT_MS`, the previous active timeout would be silently leaked, and two `ws.terminate()` calls could race. Additionally, after the timeout *fires* it doesn't reset `pongTimeout = undefined`, so `clearKeepalive()` ends up calling `clearTimeout` on an already-dead timer (harmless, but the `!== undefined` guard becomes unreliable).

A more robust pattern that is immune to constant changes:

```suggestion
          pingInterval = setInterval(() => {
            clearTimeout(pongTimeout);
            pongTimeout = setTimeout(() => {
              opts.runtime.error?.("mattermost websocket pong timeout, terminating connection");
              ws.terminate();
              pongTimeout = undefined;
            }, PONG_TIMEOUT_MS);
            ws.ping();
          }, PING_INTERVAL_MS);
```

How can I resolve this? If you propose a fix, please make it concise.

Avoid assuming keepalive APIs on injected sockets

createMattermostConnectOnce still accepts any MattermostWebSocketLike from webSocketFactory, but the new keepalive path now unconditionally calls readyState, OPEN, once, ping, and removeListener, which are not part of that interface (extensions/mattermost/src/mattermost/monitor-websocket.ts defines only on/send/close/terminate). This introduces a runtime crash path for valid injected sockets (including the existing test fake in extensions/mattermost/src/mattermost/monitor-websocket.test.ts) once the 30s keepalive interval runs, because ws.once/ws.ping can be undefined and throw a TypeError instead of reconnecting cleanly.

Useful? React with 👍 / 👎.

Gate keepalive calls to APIs outside socket contract

createMattermostConnectOnce still accepts any MattermostWebSocketLike from webSocketFactory, but the new keepalive path calls once()/ping() (and later removeListener()/readyState) that are not part of that contract. Any injected socket that previously worked by implementing only on/send/close/terminate will now throw a TypeError once the 30s interval fires, which aborts the monitor loop instead of reconnecting cleanly.

Useful? React with 👍 / 👎.

Preserve core registration of default context engine

registerContextEngine() now always delegates to registerContextEngineForOwner(..., "public-sdk"), but the new owner guard rejects non-core registrations for the default context-engine slot (legacy). Core initialization still calls registerContextEngine("legacy", ...) via registerLegacyContextEngine, so that registration now returns { ok: false } and is silently ignored, leaving the default engine unregistered; subsequent resolveContextEngine() calls with default config fail with "Context engine "legacy" is not registered" during normal agent startup paths.

Useful? React with 👍 / 👎.