fix(core): make MCP errors self-describing - #52418

Summary

MCP failures often reached users and the model as messages that could not be acted on without logs, and some never reached either:

• MCP server is not connected: no server name and no reason.
• Connection closed: a local server crashing, a remote stream dying, and an intentional close all looked the same.
• Background transport failures (for example the standalone SSE stream answering 409) were dropped entirely because the client never set onerror.
• The HTTP status and network error code lived only on error properties, so they were lost when errors were flattened to messages.

Changes:

• Descriptive errors. Errors leaving the MCP client include the HTTP status and the network error code (ConnectionRefused, ENOTFOUND) when the message lacks them.
• Close reasons. The client keeps the last transport error. It is appended to connect failures, to calls that fail with Connection closed, and to the server's failed status when a live connection drops.
• Local server exits. An unexpected exit is reported with its exit code and the end of stderr.
• Tool call errors. Unavailable servers explain their state and how to fix it; call failures name the tool and server.
• Background errors are logged as mcp transport error. Aborts from closing and teardown failures already logged on their own are skipped.

Examples, before → after:

Connection closed
→ Connection closed: MCP server process exited with code 3: Error: FOO_API_KEY is not set

MCP server is not connected
→ MCP server "github" is not connected: Connection closed: MCP server process exited with code 1: TypeError: ... Reconnect it from /mcps.

Unable to connect. Is the computer able to access the url?
→ Unable to connect. Is the computer able to access the url? (ConnectionRefused)

Error POSTing to endpoint: <html>bad gateway</html>
→ Error POSTing to endpoint: <html>bad gateway</html> (HTTP 502)

Request timed out
→ MCP tool "search" on server "docs" failed: Request timed out

(nothing)
→ WARN mcp transport error { server, error: "Failed to open SSE stream: Conflict (HTTP 409)" }

Session-expiry handling is unchanged: only 404 and the 400 "Server not initialized" response trigger reconnection; a 409 is reported, not treated as expiry.

Verification

bun test test/mcp.test.ts test/mcp-oauth.test.ts and bun run check pass.