fix(integrations): propagate facade close requests

[shrey150]

Summary

• carry the existing Playwright-compatibility closeRequested signal through StagehandFacadeTools
• let each host provide the resource cleanup callback it owns
• make the Core stdio host detach and close its Stagehand/browser resources
• preserve both model-execution and cleanup failures when they happen together

Why

The Stagehand V4 compatibility runtime already recognizes await browser.close(), but the facade previously dropped that signal when returning the model value. Code Mode could therefore report a successful close while the Node host still retained its browser resources. Cleanup belongs in the host because the browser-side worker does not own host credentials or session state.

This is complementary to #2818: stagehand.close() now disposes a Stagehand instance while intentionally leaving its browser open; this PR transports a model-authored compatibility browser.close() request to the host that owns and can terminate that browser.

Discovery and reproduction

This was found experimentally while running the official Eve integration against live Browserbase sessions, not from a type or mock failure. A browser task returned successfully after model code called await browser.close(), but the Browserbase API still reported the session as RUNNING, and the next tool call reused the same facade and session.

The trace led to the dropped boundary: the worker-side runtime set closeRequested, while StagehandFacadeTools returned only the model value/error and the host never saw the close request.

Minimal live reproduction on the affected implementation:

1. Launch the facade on a Browserbase session and retain it as the host's current resources.
2. Run await browser.close(); return "closed"; through StagehandFacadeTools.run().
3. Observe that the call returns "closed".
4. Request the facade again or make another tool call.
5. Observe the same resources are reused and the remote session remains RUNNING.

The signal-loss bug is deterministic whenever execution reaches compatibility browser.close(): the flag had no path out of the batch result. Agent-level symptoms can look less consistent when a model omits close or an earlier browser error prevents it from reaching close. In the exact live A/B, the baseline reproduced on 1/1 close attempt; in the broader eight-task official-integration baseline, cleanup succeeded through this path on 0/8 tasks.

This is distinct from the intermittent Undici socket-close error seen during earlier Eve-fork teardown testing: that was a false-negative reported by 1/3 focused close calls even though all three remote sessions reached COMPLETED. #2824 fixes the official facade's deterministic loss of closeRequested, where the remote session actually remained RUNNING.

Behavior	Before	After
Worker close request	Recorded inside the compatibility runtime, then discarded	Returned in the batch envelope
Facade result	Returned before host cleanup	Awaits the host lifecycle callback
Next tool call	Reused the same facade/session	Creates fresh resources after cleanup
Remote Browserbase state	Remained RUNNING in the exact repro	Reached COMPLETED
Execution plus cleanup failure	Only the execution path was represented	Both errors are preserved

This is the prerequisite for #2821; #2822 remains the optional web-tool follow-up.

Validation

• Exact live A/B: baseline reused the facade and left the session RUNNING; the fixed path created fresh resources and completed both probe sessions
• Eight-task official-integration rerun: Browserbase cleanup improved from 0/8 tasks to 9/9 owned sessions COMPLETED (one task created a recovery replacement)
• Core facade unit tests: 28/28
• Core package typecheck and build
• Eve packed-consumer Browserbase smoke: navigation, snapshot, hydrated action, screenshot, error recovery, close, and fresh-session recreation

No changeset is included because the Core integration package is private.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e2d5fad

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>