Fix Client message loop spinning at 100% CPU on stream EOF

[piersdd]

Summary

When a transport stream finishes (e.g. subprocess death closes the pipe), the Client's message handling loop spins at 100% CPU indefinitely.

The root cause is the repeat { ... } while true outer loop in Client.connect(transport:) (line 217). When the for try await data in stream loop exits normally on stream EOF, the repeat re-enters connection.receive(), gets an instantly-finishing stream, and loops again — consuming a full CPU core.

The Task.isCancelled check at the top of the repeat body only helps if disconnect() was called externally. On a normal subprocess/transport death, no cancellation is signalled — the stream simply finishes.

Server.swift in this same package does not have this bug — it uses a flat do { for try await ... } without an outer repeat loop.

Fix

Remove the repeat { ... } while true wrapper, matching the Server.swift pattern. The message handling task now:

1. Calls connection.receive() once
2. Iterates the stream with for try await
3. Exits cleanly when the stream finishes (EOF) or an error is thrown

The catch for isResourceTemporarilyUnavailable (which used continue to re-enter the repeat) is also removed. That EAGAIN-style error is a transient I/O condition handled internally by the transport's read loop — it does not surface through the AsyncThrowingStream that receive() returns.

Reproduction

1. Start a Client connected via StdioTransport to a subprocess
2. Kill the subprocess (or let it exit)
3. Observe the Client's task consuming 100% CPU via sample or Activity Monitor

The tight loop shows up as:

Client.connect(transport:) → AsyncThrowingStream.Iterator.next() → repeat

Test plan

• Existing test suite passes (545 tests in downstream consumer, SDK tests unmodified)
• Verified CPU drops from 88–99% to 0% after subprocess death
• disconnect() still terminates the loop correctly (cancels the task)
• Normal message handling unaffected (stream stays open while transport is alive)

[deseven]

Thank you so much, this solved my problem with randomly hanging tests where I run hundreds of tools quickly.

[piersdd]

Rebased onto current main (a0ae212, including #223) so this is mergeable again.

This was already approved, and the July comment from @deseven said it unblocked hanging tests under rapid tool use. Happy to rebase again if needed.