why

this PR wires the HTTP transport into sdk initialization, so that gateway & cache requests are sent by the connected TS, python, or Go client

what changed

• registered bb request handlers before worker initialization in all three SDKs, so requests can run during initialization, ordinary calls, batch, & close
• resolved bb connection settings in the SDK. worker initialization now sends transport availability & browser session metadata; public connection options remain accepted & validated by each SDK
• preserved browser-factory precedence, regional endpoints, API URL overrides, direct-provider model configuration, & custom callback registration
• kept handlers available while the worker finishes active calls, then disposed them on close or failed initialization

note:

the client transports return redirect responses to the worker instead of following them automatically. the previous worker transport followed redirects

test plan

• SDK lifecycle tests exercise requests before initialization completes, during batch, & while close is pending, plus cleanup after initialization failure.
• real Chromium tests in each SDK cover ordinary & batch Gateway calls, cache hits, custom callbacks, per-call model overrides, & cache failure fallback.
• direct-provider configuration is covered alongside a cache hit that skips inference.
• local HTTP fixtures verify operation counts, endpoint selection, & session settings without requiring live bb or model services.
• compatibility tests cover rejecting a worker that predates this transport & the transitional worker continuing to accept older clients.

---

Summary by cubic

Routes Browserbase Model Gateway and cache HTTP requests through the connected TypeScript, Python, and Go SDK clients instead of the worker, so the client's connection is used during initialization, ordinary calls, batch, and close.

Behavior changes

• Each SDK now resolves and validates Browserbase connection settings; worker init receives transport availability and browser session metadata instead of the API key and URL.
• Browser-factory key precedence, regional endpoints, API URL overrides, direct-provider model configuration, and custom callbacks are preserved.
• Browserbase request handlers stay registered while the worker finishes active calls and are disposed on close or failed initialization.
• Client transports return redirect responses to the worker instead of following them; the previous worker transport followed redirects.
• API URLs must use an HTTP or HTTPS scheme, include no query string or fragment, and omit a trailing /v1.

Compatibility

• Clients now require protocol 2.2.0; older workers are rejected, while a 2.2.0 worker still accepts older clients.