fix: use async_maybe_transform in AsyncMessages.stream() to avoid blocking event loop

[MaxwellCalkin]

Summary

Fixes #1195

AsyncMessages.stream() calls the synchronous maybe_transform() instead of async_maybe_transform(), causing _transform_recursive to block the event loop. This is especially impactful for large message payloads in async contexts (e.g., FastAPI gateways), where profiling shows ~5-8% CPU time spent in the blocking recursive walk.

Changes

• src/anthropic/resources/messages/messages.py — AsyncMessages.stream(): Wrapped the _post call in an inner async def make_request() coroutine that uses await async_maybe_transform(). The coroutine object is passed to AsyncMessageStreamManager (which accepts any Awaitable), so the public API is unchanged — callers still use async with client.messages.stream(...) as stream: without needing await.

• src/anthropic/resources/beta/messages/messages.py — Same fix for AsyncMessages.stream(), plus a fix for AsyncMessages.parse() which had the same sync maybe_transform issue.

Why the inner coroutine approach?

The stream() method is intentionally a non-async def that returns an AsyncMessageStreamManager. Making it async def would break the public API (users would need async with await client.messages.stream(...) instead of async with client.messages.stream(...)). By wrapping the transform + post in an inner async def make_request(), we defer both the transform and the HTTP call to the __aenter__ phase of the context manager, keeping the API unchanged while ensuring the transform runs asynchronously.

Note for maintainers

This is Stainless-generated code. The fix should be ported to the codegen template so it persists across regenerations. Specifically, the stream helper template for async classes should use async_maybe_transform instead of maybe_transform.

Test plan

• Verify async with client.messages.stream(...) still works without await
• Verify the transform runs on the event loop (not blocking) by profiling with large payloads
• Run existing test suite to confirm no regressions