Agent's browser live in the right panel

[stippi]

Shows the agent's browser live in the right panel, next to the review view (steps 1–4 of docs/browser-panel-plan.md). Chrome keeps running headless in its own process; the panel mirrors it over a CDP screencast. The GPUI part sits behind the Cargo feature browser-panel, which is on by default.

What the panel does

• Review | Browser switch in the panel header, remembered per session. When the agent opens its first browser, an open panel switches to it.
• Live view of the agent's active tab, or of a tab the user picked. Browsers of running sub-agents are listed as well. A short pulse marks where the agent clicks.
• Take control:
  • The user's mouse, wheel and keyboard go to the page: macOS editing shortcuts carry their command, input methods compose through EntityInputHandler, and copy, cut and paste use the system clipboard.
  • The toolbar gives back, forward, reload and an editable address.
  • While the user has control, the agent's browser tools fail at once with a clear message. After the hand-back, the next result tells the agent where the tab is now.
• Lifetime: a throwaway browser that is being watched survives the end of the turn and closes when the last viewer lets go.

Layers

• web:
  • one screencast pump per tab, shared by live views and record, running only while someone watches;
  • a watchable tab state: address, title, loading; popups are adopted without a tool call;
  • raw user input;
  • view guards on the manager;
  • an instance number per launched browser.
• code_assistant_core:
  • SessionBrowsers covers the agent's browsers plus those of running sub-agents;
  • UiEvent::BrowsersChanged carries metadata only, never frames;
  • SessionService::{watch_browsers, browser_view, set_browser_control};
  • BrowserView with an ordered input queue.
• ui_gpui: right_panel/browser/ (view, toolbar, input, key mapping, geometry). The view switch of the left sidebar became the shared segmented_switch.

Fixes found on the way

• main is no longer #[tokio::main]. GPUI's event loop ran inside one never-ending poll of tokio's block_on, so tokio's cooperation budget on the main thread was never renewed. After about 128 operations, every tokio watch/broadcast awaited in a GPUI foreground task stayed pending. The panel froze while the screencast went on. This may explain other stalls seen on the main thread.
• A screencast start that fails because the page navigates under it (Cannot find context with specified id) is retried.

Testing

• web: tests against real Chrome for live frames, recording during a live view, a start during navigation, tab state and popups, viewer lifetime, user control and raw input.
• core: listing and events, sub-agent registration, views keeping a browser, input only under user control, reopened browsers.
• ui_gpui: tests for the geometry mapping, the key mapping and address schemes.
• Manually, in a release build: a GPT-6.1 run driving a WebGL page (lunar-walk). The panel keeps up with 60 fps at about 4 ms decode per frame.
• cargo clippy --all-targets --all-features -D warnings is clean, and so is a build with --no-default-features --features gpui-frontend.

Not in this PR

• The <select> overlay and file chooser (step 5) wait for the CEF decision.
• a_hung_page_fails_fast failed twice under load early on this branch and could not be reproduced afterwards.