PaymentTransport rejects async streaming requests before a 402 response

[Osraka]

Summary

PaymentTransport currently rejects an async-generator request body before it sends the initial request. As a result, wrapping a normal endpoint that returns 200 turns an otherwise valid streaming upload into PaymentError, even though the payment retry path is never entered.

Reproduction

Use PaymentTransport(methods=[], inner=httpx.MockTransport(...)) with a POST request whose content is an async generator. Have the inner transport read the body and return 200. On current main, handle_async_request raises:

Streaming request bodies (async generators) are not supported through the payment retry flow.

The inner transport is not called.

Expected behavior

A non-replayable stream should be allowed to make its initial request. If that response is not 402, the response should pass through unchanged. If the initial response is 402, the transport should still reject the paid retry because it cannot safely replay the body.

Proposed scope

Keep the existing buffering and replay behavior for bytes, form data, and multipart bodies. For an async-generator body, defer the unsupported-stream error until after the initial response is known to be 402.

Regression coverage

• async-generator POST plus 200: the inner transport receives the full body and the caller receives 200;
• async-generator POST plus 402: exactly one request is sent and the retry remains rejected;
• existing buffered-body retry tests remain unchanged.

This appears to be a narrow follow-up to #166. I can prepare the regression test and minimal patch if this behavior is desired.

[bennytimz]

Good catch, this is a real gap in #166. The pre-dispatch check was meant to guarantee we never silently buffer or drop a non-replayable stream, but raising before the initial request also breaks the non-402 path, which was never the intent.
Since this came from my PR I'd like to fix it: I'll move the check into the 402 branch so an async-generator body makes its initial request normally, passes through any non-402 response unchanged, and only raises PaymentError when a paid retry would actually require replaying it. I'll include the three regression cases you listed. PR incoming shortly