fix: handle ClosedResourceError when logging errors to disconnected clients

[giulio-leone]

Problem

When a client disconnects mid-request in a stateless streamable-HTTP session, _handle_message catches the resulting Exception (e.g. ClientDisconnect) and tries to call session.send_log_message() to notify the client about the error. Since the session write stream is already closed at this point, this raises ClosedResourceError, which is unhandled inside the TaskGroup and crashes the entire stateless session with an ExceptionGroup.

Root Cause

In lowlevel/server.py, the Exception branch of _handle_message (line ~418) unconditionally calls send_log_message(). This works fine when the client is still connected, but when the error is a client disconnect, the write stream is already closed, so send_log_message → send_notification → _write_stream.send() raises ClosedResourceError.

This is a different code path from what PR #1384 fixed (message router loop). This bug is in the error recovery path:

catch exception → try to log it to client → write stream closed → crash

Fix

Wrap the send_log_message() call in a try-except that catches anyio.ClosedResourceError and anyio.BrokenResourceError, since failing to notify a disconnected client is expected and harmless. A warning is logged instead.

Testing

Added 3 tests:

• test_exception_handling_tolerates_closed_write_stream — ClosedResourceError is caught
• test_exception_handling_tolerates_broken_write_stream — BrokenResourceError is caught
• test_exception_handling_closed_stream_with_raise_exceptions — original exception is still re-raised when raise_exceptions=True

All 9 exception handling tests pass (2 consecutive clean runs).

Related Issues

• MCP server in the HTTP Streamable mode broken #1190, _handle_stateless_request ClosedResourceError #1219, ClosedResourceError when using FastMCP(..., stateless_http=True, json_response=True) with MCP Inspector #1658 — all partially fixed by PR fix: handle ClosedResourceError in StreamableHTTP message router #1384 (message router path only)
• This fixes the remaining _handle_message → send_log_message path

Fixes #2064