Retryable responses are abandoned without canceling their bodies

src/core.ts:490-495 の retry ブランチから開始し、提供された再現手順を実行して、キャンセルされていないレスポンスボディを確認します。retryRequest() の前にランタイム互換のクリーンアップを追加し、その後、Web と Node の両方のストリーム実装でキャンセルをテストして、最初のレスポンスが retry の前にキャンセルされることを確認します。

Description

When an HTTP response is retryable, the SDK starts the next attempt without consuming or canceling the previous response body.

The early return at src/core.ts:490-495 bypasses response.text() and does not call response.body.cancel() (or the runtime-equivalent cleanup) before retryRequest().

Reproduction

import Browserbase from '@browserbasehq/sdk';

let attempts = 0;
let cancelCalls = 0;
const client = new Browserbase({
  apiKey: 'test',
  maxRetries: 1,
  fetch: async () => {
    attempts++;
    if (attempts === 1) {
      const body = new ReadableStream({
        cancel() {
          cancelCalls++;
        },
      });
      return new Response(body, {
        status: 500,
        headers: { 'content-type': 'text/plain' },
      });
    }
    return new Response('{}', {
      status: 200,
      headers: { 'content-type': 'application/json' },
    });
  },
});

await client.get('/retry');
console.log(cancelCalls); // 0

Expected behavior

The unused body of the first response is canceled before retrying (cancelCalls === 1).

Actual behavior

The response is abandoned without cancellation (cancelCalls === 0).

Why this matters

With streaming or large error responses, abandoning the body can keep sockets and stream resources occupied, reduce connection reuse, and accumulate resources across repeated 429/5xx responses. The retry branch should explicitly cancel the body in a runtime-compatible way and test both Web and Node stream implementations.

Tested against @browserbasehq/sdk 2.18.0 / current main (b781bd7).