fix(client): tolerate invalid UTF-8 from server stdout in stdio_client

[Bartok9]

Summary

• Default StdioServerParameters.encoding_error_handler to "replace" so a server emitting malformed UTF-8 no longer crashes the client transport.
• Malformed bytes now surface as an in-stream JSON parse error and the transport stays alive for subsequent valid messages.

Motivation

Closes #2454.

stdio_client() decoded child stdout with encoding_error_handler="strict". When a spawned server writes invalid UTF-8 bytes to stdout, the UnicodeDecodeError raised during TextReceiveStream iteration escapes the decode loop's except clauses and tears down the transport task group — it surfaces as an ExceptionGroup out of the context manager instead of being delivered as a normal in-stream parse error.

The issue itself points at the analogous server-side hardening (#2302, errors="replace" on stdin), which deliberately chose to: replace invalid bytes with U+FFFD, let JSON validation fail on the malformed line, and keep the transport alive. This change brings the client to parity: defaulting encoding_error_handler to "replace" means the bad line fails JSON-RPC validation and is delivered as an Exception via _parse_line, while later valid messages still come through.

Verification

• uv run pytest tests/client/test_stdio.py -q — 34 passed, 1 skipped
• uv run pytest tests/client/ tests/interaction/transports/test_stdio.py -q — 238 passed, 1 skipped, 1 xfailed (no regression from the default change)
• New regression test test_invalid_utf8_mid_session_surfaces_as_an_in_stream_exception fails without the fix (5s task-group hang) and passes with it.
• Manual repro from the issue (\xff\xfe\n followed by a valid ping) crashed the task group on main with an ExceptionGroup(UnicodeDecodeError, ...); with the fix it surfaces a ValidationError then reads the following valid message.
• ruff format --check + ruff check + pyright clean on both changed files.

Notes

• Salvages the intent of the stale, now-conflicting fix(stdio_client): tolerate invalid UTF-8 from child stdout #2456 by @shaun0927 (same root cause + default flip), rebuilt cleanly against current main after the transport was refactored. The decode/drain plumbing moved, so this is a fresh implementation on the new code path with a mid-session regression test (distinct from the existing test_invalid_utf8_flushed_by_a_dying_server_does_not_break_shutdown, which only covers the raw-bytes shutdown drain).

[Bartok9]

CI note: the one red cell (`test (3.13, lowest-direct, windows-latest)`) is a flake unrelated to this change. It failed on `tests/interaction/transports/test_stdio.py::test_tool_call_and_notification_round_trip_over_a_stdio_subprocess` with `assert captured_stderr == "stdio-echo: clean exit\n"` getting `` — i.e. the server child was escalation-killed on a loaded Windows runner before it could flush its clean-exit line. That is a server-side shutdown-timing assertion in a different test file; this PR only changes client-side stdout decoding in `src/mcp/client/stdio.py` (+ `tests/client/test_stdio.py`). The same `lowest-direct/windows` config passed on 3.10/3.11/3.12/3.14, and the aggregate `all-green` check is green. Local run on this branch: `uv run pytest tests/client/test_stdio.py` → 34 passed, 1 skipped. A re-run of the failed job should clear it (I don't have repo admin to trigger it).