feat(remote): report why the relay connection died

[veksen]

Goal

The persistent analyzer's connection to the relay breaks and reconnects roughly every 65 seconds, and has done for at least 19 days. Neither side records why. This PR adds the two lines needed to find out. It changes no behaviour and fixes nothing on its own.

The follow-up is the delivery fix in the PR stacked on top of this one, which stops a push lost to that connection from being recorded as delivered.

What

Before: a broken connection logged Connection broken: Error: WebSocket connection failed. and nothing else. That message is the same whether the server terminated the client, the network dropped, or the process closed the socket itself.

After: the WebSocket close code and reason are logged alongside it. A stalled event loop is reported once it passes five seconds.

How

ApiClient.connect now constructs the WebSocket and hands it to capnweb, instead of passing a URL string for capnweb to open. That is the only way to see the close frame, since capnweb collapses every failure into one message. Verified against api.querydoctor.com that capnweb drives a caller-constructed socket: the server's auth check replies in 1.2s.

watchEventLoopLag is a one-second interval that measures its own drift. It exists because the relay's pong is answered by the transport on the same event loop, and the server terminates any client that misses one 30-second heartbeat. A process pinned by CPU work is therefore indistinguishable, from the server's side, from one that has died, and nothing currently records the difference. It runs only on the persistent path, holds the process open via unref, and costs one subtraction per second.

Tests

No new tests. Both changes are log lines, and the one behavioural risk — whether capnweb accepts a socket it did not open — was checked against production rather than mocked.

Existing suite passes: 440 tests across 43 files. npm run typecheck and npm run build are clean.

What these lines are expected to show, once deployed: a close code of 1006 with an empty reason at each break, preceded by an event-loop stall over 30 seconds. If the stall is absent, the diagnosis is wrong and the cause is on the network rather than in the process.

[github-actions]

Query Doctor — 6 successful checks

 Cost regression — No query went up more than 5%
 Untested data access — No changed data-access file without a test
 New query — No new queries
 New query with index recommendation — No new query ships an index recommendation
 Schema drift — No schema changes
 High-value nudge — No index or rewrite past the threshold

---

_{More details via MCP → get_ci_run({ runId: "019ff786-1330-72f2-b94f-1ce4f44f1054" }) · view run · docs
3 queries read against main on assumed statistics of 10,000,000 rows per table. Sync production stats for costs measured against your real data.}