gemini-cli 0.58.0 hangs (retry-backoff) when play.googleapis.com is unreachable but the API endpoint is reachable; usageStatisticsEnabled:false does not stop the call

## What happened?

In a non-interactive run (`gemini -p "..." -m gemini-3-flash-preview --approval-mode yolo`), the CLI never returns and produces no output when `play.googleapis.com` is unreachable — even though the model API host `generativelanguage.googleapis.com` is reachable and the request would otherwise succeed. It appears to enter a retry-with-exponential-backoff loop and effectively hangs indefinitely.

### What we observed

1. Capturing outbound HTTPS via a local logging CONNECT proxy (`NODE_USE_ENV_PROXY=1`, `HTTPS_PROXY`), gemini-cli 0.58.0 connects to TWO hosts on a normal run:
- `generativelanguage.googleapis.com:443` (the model API — expected)
- `play.googleapis.com:443` (unexpected; Google logging/clearcut endpoint)
2. On an open network (both reachable) the CLI works normally and answers.
3. In the egress-filtered environment where **only `play.googleapis.com` is blocked and the model host `generativelanguage.googleapis.com` is reachable**, the CLI still hangs and yields empty output — it never returns.
4. Setting `{"usageStatisticsEnabled": false}` in `~/.gemini/settings.json` does NOT stop the connection to `play.googleapis.com` (verified via the same proxy capture).

Secondary observation (not the primary cause, included only to show the retry loop is unbounded rather than fail-fast): under `--network none` (everything blocked, including the model host) the CLI does not exit either — it loops indefinitely with:
```
Attempt N failed. Retrying with backoff... Error: exception TypeError: fetch failed sending request
```
from `retryWithBackoff` → `GeminiChat.makeApiCallAndProcessStream` → `Models.generateContentStream`. This trace reflects the all-blocked case (model path failing), not the only-`play`-blocked case above; it is offered as evidence that the backoff loop has no bounded termination, not as the cause of the egress-filtered hang.

## What did you expect to happen?

- Calls to `play.googleapis.com` (usage stats / telemetry / logging) should be non-blocking and fail-fast — a blocked telemetry endpoint must never stall or prevent the primary model response.
- `usageStatisticsEnabled: false` should fully disable any egress to `play.googleapis.com`.
- For restricted / air-gapped / egress-filtered environments, the required set of endpoints should be documented, and non-API endpoints should be optional.

## Client information

- gemini-cli **0.58.0**, Node **v24.14.1**, **Linux arm64** (container).

## Login information

- Auth: `GEMINI_API_KEY` (Gemini API, not Code Assist / Vertex).

## Anything else we need to know?

**Environment:** an egress-filtered sandbox (DNS allowlist) that permits `generativelanguage.googleapis.com` but NOT `play.googleapis.com`.

**Impact:** breaks gemini-cli in egress-filtered / allowlisted / air-gapped environments even when the model API host is explicitly allowed — the process hangs rather than degrading gracefully.

**Workaround:** allowlisting `play.googleapis.com` in the egress filter restores normal operation.

**Relation to prior issues:** #1717 (and related #1599 / #1539 / #1425) addressed a *crash* (unhandled promise rejection) when `play.googleapis.com` / clearcut telemetry was unreachable, fixed in the v0.1.x line. This report is a distinct *hang* on 0.58.0 — the process does not crash, it stalls indefinitely — and `usageStatisticsEnabled: false` still does not suppress the call to `play.googleapis.com`.

Reproduce the non-interactive command with the proxy and the egress-filtered setup described in the issue. Start with retryWithBackoff, GeminiChat.makeApiCallAndProcessStream, and Models.generateContentStream, then check ~/.gemini/settings.json handling. Done means a blocked play.googleapis.com does not stall a reachable model request, usageStatisticsEnabled:false suppresses that call, and failed requests terminate instead of retrying indefinitely.

Written by the indexing model from the issue text.