Node transport: an HTTP-refused request POST errors the whole connection (TUI never shows the #2722 refusal) #2776

Found during the v2.12.0 release smoke (#2764), while verifying #2722 in the TUI.

Problem

On the Node transport, a request POST that the server refuses with a bare HTTP 400/403/404/405 errors out the whole connection. The SDK's StreamableHTTPClientTransport._send calls this.onerror?.(error) before rethrowing, and InspectorClient's baseTransport.onerror then sets the status to error, even though the same error also rejects the request that sent it.

That is why the TUI's new #2722 refusal line, Listen stream: refused by the server, can't be reached on a real server. Driven through a real pty against subscriptions-listen-refused-http.json (modern), the connect-time listen 403 turns the client into ✗ error / Error POSTing to endpoint: Forbidden before the Subscriptions tab can show. PR #2730 listed this as pre-existing and out of scope. The same thing happens for any refused request on the Node transport, such as #2721's bare 403 on tools/call. The web client is unaffected, because its remote transport does not route send failures through onerror.

Expected

A deterministic HTTP refusal of a POST is a refused request, not a failed connection. It reaches the caller as the request's rejection, so onerror should leave the connection status alone for it. "Deterministic HTTP refusal" uses the classifier #2722 already defines: SdkHttpError, ClientHttpNotImplemented, status 400/403/404/405. The SDK throws that code only from its POST path, so a failure with no other surface (an SSE GET stream erroring, a dropped connection, a 5xx) still flips the status as today, and auth failures still go through their own codes.

On the TUI, against the refusing fixture, the client stays connected, sends one listen, and shows Listen stream: refused by the server with the HTTP status.