Flush the connection log buffer after N failed reconnect attempts against an unreachable server #1112

Background

DEVEX-669 (#1100) added BufferingLogger, which flushes buffered below-level connection logs into the "Coder" output channel on a genuine, surfaced connection failure:

• a reconnecting WebSocket terminal failure (unrecoverable_close, unrecoverable_http, or certificate_error; a handshake 401 is excluded because a token refresh reconnects the same socket);
• a failure while opening a workspace (canceled build, missing agent, timeout, or CLI/certificate error).

During Ehab's review of #1100 we agreed to defer one additional trigger: flushing after N consecutive failed reconnect attempts against an unreachable server.

Problem

When a server is simply unreachable, the reconnecting WebSocket keeps retrying with backoff and never reaches a terminal failure reason, so the buffer is never flushed. A user reproducing a "can't connect / hangs on connecting" problem therefore gets no buffered detail in their support bundle, even though plenty of below-level context was captured.

Proposal

Flush the connection log buffer once a reconnect loop has failed N consecutive times (i.e., treat sustained unreachability as a genuine failure worth surfacing), then avoid re-flushing on every subsequent attempt until a successful connect resets the counter.

Open questions to settle during implementation:

• Value of N (or a time-based threshold instead of / in addition to a count).
• Where the counter lives and how it resets on a successful open.
• Guarding against repeated flushes while still stuck (flush once per failure "episode").
• A meaningful flush reason/route for attribution, consistent with the existing terminal-failure reasons.

References

• PR feat: buffer connection logs and flush them on failure #1100 (DEVEX-669)
• src/websocket/reconnectingWebSocket.ts, src/logging/logBuffer.ts

🤖 Filed by Coder Agents on behalf of @aqandrew, following up on the #1100 review.