fix(computer_use): expose dispatch param for all input actions

[Sahil-SS9]

Fixes #57623

Description

Add a dispatch parameter (background | foreground | auto) to the computer_use tool schema and wire it through _dispatch() for all mutating actions: click, double_click, right_click, middle_click, drag, scroll, type, key, and set_value.

Problem

On Windows, default background dispatch uses UIA hit-test → UIA Invoke, which silently fails on several common UI frameworks:

• Explorer desktop icons (SysListView32) — drag operations essentially never work
• Qt apps (WeChat, Telegram) — clicks are silently dropped

PR #55048 introduced a dispatch override for click variants, but it bypassed the backend methods and called _action directly — and critically, the dispatch parameter was never declared in the tool schema, so the model could never actually produce it. Drag, scroll, type, key, and set_value had no override path at all.

Fix

1. Schema (schema.py): Declare dispatch as an optional string enum [background, foreground, auto] in the tool schema, applicable to all mutating actions.
2. Dispatch layer (tool.py): Read args.get("dispatch") and pass it to every backend method (click, drag, scroll, type_text, key, set_value). When omitted or None, behavior is unchanged — the backend receives dispatch=None and uses its default (background).
3. Backend ABC (backend.py): Add dispatch: Optional[str] = None to the abstract signatures for click, drag, scroll, type_text, key, and set_value.
4. CuaDriverBackend (cua_backend.py): Accept dispatch in each method and pass it through to _action() as a field in the MCP tool args dict. Only included when non-None to avoid sending it to older cua-driver versions that don't recognize it.
5. NoopBackend (tool.py): Updated to accept and record dispatch for test assertions.

When dispatch is omitted, every code path produces identical behavior to before — the parameter is purely additive.

Verification

• pytest tests/tools/test_computer_use.py::TestSchema tests/tools/test_computer_use.py::TestDispatch tests/tools/test_computer_use.py::TestSafetyGuards -q → 42 passed (34 existing + 8 new dispatch routing tests)
• pytest tests/tools/test_computer_use_capture_routing.py tests/tools/test_computer_use_vision_routing.py -q → 44 passed
• Compile check on all 4 modified source files
• The one pre-existing failure (TestCuaEnvironmentScrubbing — ModuleNotFoundError: No module named 'mcp') is unrelated and fails identically on main
• New tests verify dispatch reaches the backend for click, drag, scroll, type, key, set_value, and defaults to None when omitted

[teknium1]

Thanks for tracing the missing schema-to-backend wiring; current main still lacks it (tools/computer_use/schema.py:106-214, tools/computer_use/tool.py:369-432).

Problems

• Issue #57623 asks dispatch="auto" to retry foreground delivery after a failed background attempt. This PR describes fallback in the new schema text, but its new paths only forward the value once; _action() makes one MCP call_tool() at tools/computer_use/cua_backend.py:2080-2101.
• The new tests assert _NoopBackend routing only. They do not exercise the actual MCP payload construction in CuaDriverBackend for the affected action tools.

Suggested changes

• Either implement the issue's verified fallback behavior, or narrow auto to an explicitly verified cua-driver pass-through contract.
• Add mocked-session CuaDriverBackend tests for click, drag, scroll, type_text, both key routes, and set_value, including omission behavior.

Automated hermes-sweeper review.

[teknium1]

auto is described as choosing or falling back, but this PR only forwards the string once to cua-driver. Issue #57623 specifically asks for verified background-to-foreground retry; please implement that behavior or narrow this description to a documented pass-through contract.

[Sahil-SS9]

Adjusted: chose the documented pass-through contract option. The auto dispatch description now states it is passed through to the cua-driver, which chooses an input-delivery mode on the agent's behalf; the agent does not resolve it locally, so the resulting mode (and any fallback) is driver-dependent. This matches the PR's actual behaviour (it only forwards the dispatch string) without overclaiming.