fix: close stdout stream explicitly to prevent CLOSE_WAIT socket leak

[olegnazarov23]

Summary

Fixes #665 — after a ClaudeSDKClient session ends, the Python process burns ~24% CPU indefinitely due to a leaked CLOSE_WAIT TCP socket keeping the event loop busy-spinning.

Root Cause

SubprocessCLITransport.close() closes stdin and stderr streams but never explicitly closes the stdout stream — it only sets self._stdout_stream = None. The underlying file descriptor remains registered in the event loop's kqueue/epoll selector.

When the subprocess exits, any TCP connections it held (e.g. to the Anthropic API) enter CLOSE_WAIT. Since the socket's FD is still registered, kqueue reports it as readable every poll cycle (EOF pending), causing asyncio to busy-spin instead of blocking.

Fix

Explicitly call aclose() on the stdout TextReceiveStream before nulling the reference. This deregisters the FD from the event loop and closes the underlying socket, breaking the spin cycle.

# Before (stdout FD leaked):
self._stdout_stream = None

# After (FD properly deregistered):
if self._stdout_stream:
    with suppress(Exception):
        await self._stdout_stream.aclose()
    self._stdout_stream = None

This follows the same pattern already used for stdin and stderr streams in the same method.

Test

Added test_close_explicitly_closes_stdout_stream — verifies that close() calls aclose() on the stdout stream and cleans up all stream references.

All 40 transport tests pass.