Remote MCP: transient 5xx (e.g. 502) on `initialize` marks server failed for the whole session with no retry/backoff

Describe the bug

When a remote (type: http) MCP server returns a transient HTTP 5xx (observed: 502 Bad Gateway) on the initialize request at session startup, the CLI records a hard, per-session failure for that server and never retries it for the remaining lifetime of the session. The server then shows as unavailable for the whole run, even though the endpoint recovers seconds later.

This is especially damaging for headless / autopilot workflow (automation) sessions, which cold-start a fresh MCP client on every run: a single unlucky 502 at startup silently disables a required connector for that entire run, with no self-heal. A long-lived interactive session that already completed initialize is unaffected, which makes the failure look inconsistent ("it's green in the app but unavailable in automation").

Observed log (one automation run; server names generic):

[ERROR] rmcp::transport::worker: worker quit with fatal:
        UnexpectedServerResponse("HTTP 502 Bad Gateway")
[DEBUG] native_host: Recorded failure for server <Remote Server>: failed to initialize MCP client …
[ERROR] Failed to start MCP client for <Remote Server>: … unexpected server response:
        HTTP 502 Bad Gateway, when send initialize request

The endpoint returned a normal 401 auth challenge (healthy) on direct probes seconds later — i.e. the 502 was transient/cold-start, not a real outage.

Affected version

1.0.79-9 (bundled SDK; buildMetadata.gitCommit 65f2c0f). Windows x64. Logic lives in the Rust MCP transport / native_host, so expected to be platform-independent.

Steps to reproduce the behavior

1. Configure a type: http remote MCP server whose upstream occasionally returns a transient 5xx on initialize (e.g. a scale-to-zero / cold-start backend behind a gateway).
2. Start a session (or let a scheduled/autopilot workflow run) so the CLI cold-starts the MCP client and sends initialize.
3. When initialize happens to hit the transient 502, observe:
   • Recorded failure for server <name> and Failed to start MCP client for <name> … HTTP 502 Bad Gateway.
   • The server stays unavailable for the entire session — no retry, no backoff, no re-initialize.
4. Probe the same endpoint directly a few seconds later → it responds normally (e.g. 401 auth challenge), confirming the 5xx was transient.

Expected behavior

Transient 5xx responses during MCP initialize should be retried with bounded exponential backoff (a few attempts over several seconds) before the server is marked failed. Ideally also allow a later lazy re-initialize/reconnect within the session rather than latching "failed" for the whole run. Distinguish transient transport/gateway 5xx (retryable) from 401/OAuth challenges (handled by the auth flow) and from 4xx config errors (not retryable).

Additional context

• Impact is amplified for scheduled/autopilot automation sessions: they re-cold-start MCP clients every run, so a single startup 502 disables a required connector for that run with no recovery, producing intermittent "connector unavailable" failures that are hard to diagnose.
• A long-lived interactive session that already completed initialize keeps working, so the same server can appear "connected (green)" in the interactive UI while every fresh automation session reports it unavailable.
• Suggested scope: retry policy on the initialize send path in the streamable-http MCP client worker; treat 5xx/transport-closed as retryable with capped attempts + jittered backoff.
• Related: the OAuth silent-refresh scope bug tracked in #4464 (a separate failure mode on the same class of remote servers). This retry issue is independent — it fires before auth, on the transport layer.
• OS: Windows x64.

Empieza siguiendo el flujo de envío de initialize del worker del cliente MCP streamable-http en el transporte MCP de Rust y el registro de fallos de native_host. Reproduce un 502 transitorio y, después, verifica los reintentos acotados con backoff, mientras que los desafíos 401/OAuth y las respuestas 4xx no reintentables conservan su tratamiento actual. Se considera terminado cuando un endpoint recuperado puede inicializarse durante la misma sesión en lugar de seguir marcado como fallido.