Keep default reconnect policy unbounded for long-lived clients

Defaulting maxReconnectRetries to 10 makes every existing GatewayClient caller stop reconnecting after roughly 3 minutes of outage, even though long-lived services currently instantiate the client without this option and rely on automatic recovery (for example runNodeHost logs "keep retrying" and then blocks forever). Once this branch calls stop(), closed is permanent for that instance, so the process will stay disconnected after transient gateway downtime until an external restart, which is a behavior regression introduced by this change.

Useful? React with 👍 / 👎.

NaN/Infinity bypasses the retry cap entirely

this.opts.maxReconnectRetries ?? 10 uses the nullish coalescing operator, which only substitutes 10 for null/undefined. If a caller passes maxReconnectRetries: NaN or maxReconnectRetries: Infinity, the nullish check passes through the bad value and the cap is silently broken:

• NaN ?? 10 → NaN; then ++reconnectCount > NaN → false forever → infinite loop (re-introduces the original bug)
• Infinity ?? 10 → Infinity; the count can never exceed Infinity → infinite loop

Every other numeric option in this file is validated with typeof x === "number" && Number.isFinite(x) (see requestTimeoutMs, connectDelayMs, tickWatchMinIntervalMs). The same pattern should be applied here:

This is a comment left during a code review.
Path: src/gateway/client.ts
Line: 643-644

Comment:
**`NaN`/`Infinity` bypasses the retry cap entirely**

`this.opts.maxReconnectRetries ?? 10` uses the nullish coalescing operator, which only substitutes `10` for `null`/`undefined`. If a caller passes `maxReconnectRetries: NaN` or `maxReconnectRetries: Infinity`, the nullish check passes through the bad value and the cap is silently broken:

- `NaN ?? 10` → `NaN`; then `++reconnectCount > NaN` → `false` forever → infinite loop (re-introduces the original bug)
- `Infinity ?? 10` → `Infinity`; the count can never exceed `Infinity` → infinite loop

Every other numeric option in this file is validated with `typeof x === "number" && Number.isFinite(x)` (see `requestTimeoutMs`, `connectDelayMs`, `tickWatchMinIntervalMs`). The same pattern should be applied here:

```suggestion
    const rawMax = this.opts.maxReconnectRetries;
    const maxRetries =
      typeof rawMax === "number" && Number.isFinite(rawMax) && rawMax >= 0
        ? Math.floor(rawMax)
        : 10;
    if (++this.reconnectCount > maxRetries) {
```

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

No test coverage for the new retry-cap behaviour

The PR description notes that the existing 20 tests pass, but none of them exercise maxReconnectRetries. There are no test cases that verify:

• The client stops after exactly maxReconnectRetries attempts
• onConnectError fires with the "limit reached" message
• reconnectCount resets to 0 on a successful hello-ok
• maxReconnectRetries: 0 stops on the first reconnect attempt

Given that this feature exists specifically to prevent the zombie-process regression from #45469, having automated tests would prevent regressions from future refactors of scheduleReconnect.

This is a comment left during a code review.
Path: src/gateway/client.ts
Line: 643-648

Comment:
**No test coverage for the new retry-cap behaviour**

The PR description notes that the existing 20 tests pass, but none of them exercise `maxReconnectRetries`. There are no test cases that verify:

- The client stops after exactly `maxReconnectRetries` attempts
- `onConnectError` fires with the "limit reached" message
- `reconnectCount` resets to `0` on a successful `hello-ok`
- `maxReconnectRetries: 0` stops on the first reconnect attempt

Given that this feature exists specifically to prevent the zombie-process regression from #45469, having automated tests would prevent regressions from future refactors of `scheduleReconnect`.

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

Restore unbounded default reconnect policy

Using this.opts.maxReconnectRetries ?? 10 changes every existing GatewayClient caller that does not set this new option from infinite reconnect to a hard stop after 10 retries (~3 minutes with current backoff), and stop() then permanently sets closed. This is a behavior regression for long-lived processes that explicitly depend on automatic recovery (for example runNodeHost documents "keep retrying" in src/node-host/runner.ts:211 and then blocks forever), so transient gateway downtime now leaves those clients disconnected until an external restart.

Useful? React with 👍 / 👎.

Keep reconnect retries unbounded by default

Using this.opts.maxReconnectRetries ?? 10 changes existing GatewayClient callers that do not set the new option from infinite recovery to a hard stop after roughly a few minutes of outage, because exceeding the cap calls stop() and permanently flips closed. I checked long-lived callers in src/node-host/runner.ts (the process blocks forever after startup and comments that reconnect is handled by the client) and src/acp/server.ts (onClose logic assumes transient disconnects are followed by auto-reconnect), so transient gateway downtime now leaves these services disconnected until an external restart.

Useful? React with 👍 / 👎.