Implement blocking dialog surfaces with synthetic controls

[lespaceman]

Parent

Parent PRD: #85

What to build

Implement blocking JavaScript dialog surfaces as the tracer-bullet path for the unified non-DOM surface model.

When a page action opens an alert, confirm, prompt, or beforeunload prompt, the action tool should return immediately with a blocking non_dom active layer instead of waiting for normal page stabilization. The returned state should expose the surface through normal snapshot control semantics: clearly prefixed synthetic element IDs, familiar kinds such as button/input/text, and surface metadata that identifies the JavaScript dialog context. Existing action tools should route synthetic IDs internally, so agents can click OK/Cancel controls and type prompt text without using a dedicated dialog tool.

Acceptance criteria

• Clicking an alert trigger returns a state response with a blocking non_dom layer and synthetic controls instead of hanging.
• Clicking the synthetic alert OK control dismisses the alert and returns normal page state.
• Clicking a confirm trigger returns accept and dismiss synthetic controls, and each control produces the expected page result.
• Clicking a prompt trigger returns a synthetic text input plus submit/cancel controls; typing into the input and submitting echoes the typed value in the page.
• Beforeunload prompts are represented as blocking non-DOM surfaces with stay/leave semantics.
• DOM regions are marked blocked or collapsed while a blocking non-DOM surface is active.
• find can discover synthetic dialog controls by label and kind.
• get_element on a synthetic dialog control explains that it is a non-DOM surface control.
• Existing high-level tests prove that no dialog-triggering action waits for normal DOM stabilization while the dialog is open.

Blocked by

None - can start immediately