CDP reconnect exhaustion leaves the connection non-terminated, so subsequent sends enqueue into a queue nothing will flush

[cacieprins]

Follow-up to #34561 / #34574, from review discussion there (Bugbot finding traced and confirmed by @AtofStryker).

Problem

When an auto-reconnecting CDPConnection exhausts its reconnection attempts (20 tries), it emits cdp-connection-reconnect-error but never sets _terminated, and CriClient never resets _connected. As of #34574, CriClient rejects the already-enqueued commands on that event — but any send() issued after exhaustion still sees a non-terminated connection, hits the disconnected-socket path, and re-enqueues into a queue that nothing will ever flush. Those promises never settle.

packages/server/lib/browsers/cdp-protocol/cdp-connection.ts (_reconnect, reconnect-exhausted branch) and packages/server/lib/browsers/cdp-protocol/cri-client.ts (send() terminated guards).

Scope / mitigation

• Only reachable on auto-reconnecting clients, i.e. the root browser client in normal runs (page-level clients are non-reconnecting and take the terminal-disconnect path added in chore: reject CDP commands when a non-reconnecting connection terminally disconnects #34574).
• Not a regression from chore: reject CDP commands when a non-reconnecting connection terminally disconnects #34574: the prior guard reduced to the same terminated check, so these sends parked forever before that change too.
• Mitigated in practice: the reconnect-exhausted path emits CDP_COULD_NOT_RECONNECT with isFatalApiErr = true, which tears the run down.

Proposed fix

Treat reconnect exhaustion as terminal, making the two _rejectEnqueuedCommands triggers symmetric: set _terminated = true (and clean up the dead connection) when asyncRetry gives up in _reconnect, so the existing terminated guards in CriClient.send() reject subsequent sends instead of enqueuing them. Unit-cover the post-exhaustion send path.

[cacieprins]

Adding a second item to this cleanup from the #34574 re-review (@AtofStryker):

.closed window between terminal disconnect and first close() call — the _closed flag only flips when close() runs, so between a terminal socket disconnect and the first close() call, CriClient.closed still reads false. A caller gating on it in that window (e.g. resetBrowserTargets gating Target.closeTarget, if Target.targetDestroyed delivery lags the ws close) sees a live client. Pre-existing (#34574 narrows it), non-blocking. Suggested fix: derive the getter — get closed () { return this._closed || this.cdpConnection?.terminated } — so the flag can't go stale, alongside making reconnect exhaustion set terminated (the main item here).