fix: scope Browser previews to each Run

[4pmtong]

Pull Request

Related Issue

Description

A Session can reuse one SSE transport for later Runs. Browser preview handoff state previously lived for the transport lifetime, so a preview shown by the first Run could suppress a later explicit preview request, and an unkeyed pending visit from the old Run could be reused by the new one.

This change scopes preview handoff state to the Run. Protection in production comes from two mechanisms:

1. Fresh handoff on Run switch. When Run ownership changes (updateLockedReferences), a new handoff is created, so a follow-up Run gets its own reveal and pending-visit state.
2. Superseded transports are rejected. ACTIVATE_TOOLKIT and completion-tail frames now pass the transport ownership gate before projection or URL recording: frames from an aborted transport, or from a transport no longer bound to the owning Run, are dropped. This covers late activations after a Resume or a restarted task.

Within a single reused transport, the backend emits the old Run's frames and the follow-up's CONFIRMED/NEW_TASK_STATE from one serial queue, so an old Run's unkeyed frame cannot arrive after the switch.

The gate also rejects frames whose explicit run_id/project_id (top level or under data) conflicts with the transport owner. This is a forward-compatible defensive layer and is inactive today: legacy /chat frames carry only step and data, with no Run or Project ids. Tests that exercise it are labelled "forward-compatible id guard".

Existing behavior remains intact: each Run reveals at most one preview, only supported local URLs are handed off, and managed-profile Browser capabilities are unchanged.

This fixes the reproduced reused-transport path. The broader historical report remains partial until the original model/tool scenario is repeated in a release build.

Testing Evidence (REQUIRED)

• I have included human-verified testing evidence in this PR.
• This PR includes frontend/UI changes, and I attached screenshot(s) or screen recording(s).
• No frontend/UI changes in this PR.

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Contribution Guidelines Acknowledgement

• I have read and agree to the Eigent Contribution Guideline