Go SDK leaks an uploaded Browserbase extension when upload-response validation fails

Start in packages/sdk-go/browserbase_session.go at the upload and extension.validate() path, then review deleteExtensionBestEffort and the cleanup paths that follow session creation. Add the focused case to packages/sdk-go/browserbase_session_test.go using fakeBrowserbaseAPI and an invalid response with a usable ID. Done means validation still fails, deleteExtensionCalls records the uploaded extension, and cleanup uses a non-canceled context while preserving any errors.

Description

The Go Browserbase launch path uploads an owned Stagehand extension and then validates the full upload response. If validation fails while the response still contains a usable extension ID (for example, createdAt is missing or fileName is empty), createSession() returns immediately without deleting the extension that was just created.

Other failure paths after a successful upload call deleteExtensionBestEffort, but the response-validation path does not. Repeated transient/malformed API responses can therefore accumulate orphaned extensions on the Browserbase account.

Code reference

• packages/sdk-go/browserbase_session.go:85-97 uploads the extension and returns directly on extension.validate() failure.
• packages/sdk-go/browserbase_session.go:106-115 correctly deletes the owned extension when session creation fails.
• packages/sdk-go/browserbase_session.go:117-130 also cleans up after an invalid session response.
• packages/sdk-go/browserbase_client.go:724-748 shows that validation can fail for fields other than id, leaving a valid ID available for cleanup.

Reproduction

Add a focused test using fakeBrowserbaseAPI in packages/sdk-go/browserbase_session_test.go:

1. Make uploadExtensionFunc return a response with ID: testPointer("ext_orphaned") but one invalid/missing metadata field, such as CreatedAt: nil.
2. Call client.createSession(context.Background(), BrowserbaseLaunchOptions{}).
3. Assert that creation fails validation.
4. Inspect api.deleteExtensionCalls.

deleteExtensionCalls remains 0, although the server-side extension ID is known.

Expected behavior

When an upload succeeded and returned a non-empty extension ID, every subsequent local validation failure should make a best-effort deletion using a non-canceled cleanup context, while preserving the validation error (and joining any cleanup error).

Actual behavior

The function returns the validation error and leaves the uploaded extension behind.

Why it matters

Browserbase extensions are account resources. A malformed or partially incompatible API response should not turn a failed browser launch into a persistent resource leak, especially for applications that retry launch automatically.

Duplicate/history check

I searched open and closed issues/PRs for Browserbase extension cleanup, invalid upload responses, and extension leaks. Existing tests cover upload errors, empty IDs, session-creation cleanup, and retrying failed deletion, but I found no issue or PR covering cleanup after upload-response validation fails.