Proposal: first-class support for Jev-style typed-choice browser agents

What this is

A proposal (requirement doc, no code changes) asking ego lite to support Jev-style typed-choice browser agents as a first-class pattern, with the performance that design is known for.

Why

The reference design, browser-use/jev-ultrafast, replaces the screenshot-plus-chat loop with an indexed DOM action space and one typed-choice request per step (operation + target in a single response). It measured a full Google Flights search in ~7 s with 91% fewer protocol calls than screenshot agents.

Two independent ports of this design already run on ego lite — romaluev/jev-ego and shikaizhong-design/jego — which suggests the demand is real. Both hit the same SDK gaps. Measured on Jego: the decision step is fast (median 0.6–1.9 s), but a Flights-class flow takes ~60 s end to end vs the upstream's ~7 s. The gap is protocol round trips and missing viewport controls, not the model.

What the doc asks for

1. Batched evaluate-and-act primitive — merge "freshness guard + hit-test + click" into one round trip instead of 3–4 sequential SDK calls, without resorting to raw Runtime.evaluate.
2. Viewport and focus emulation control — expose setViewportSize and focus emulation per Page, so agents get deterministic geometry and rendering instead of inheriting the user's window size and foreground animation timing.
3. (Optional) First-class indexed action space — e.g. page.actionSpace(), so every agent stops re-implementing the same accessible-element collector; aligns with WebMCP.

Performance targets are stated measurably in the doc (median decision-to-input ≤ 2 s, 1–2 round trips per step, Flights-class flow in the ~10 s range).

Scope

Documentation only: docs/jev-typed-choice-agent-requirement.md, following the style of the existing docs/*-requirement.md files. Happy to contribute the SDK-side helper, tests, and benchmark runs if the direction looks good.