cua-driver/Windows: preserve UIA unavailability during WebView2 background clicks

[f-trycua]

Primary area

Cua Driver

Summary

A WebView2 background pixel click can fall through to Windows message delivery
while UIA is cooling down after a slow provider call. The action reports
effect: "unverifiable", but the fixture does not observe the click. The
canonical E2E assertion correctly fails.

Reproduction

1. Run the canonical Windows native harness on an interactive desktop using
   .\scripts\ci\windows\run-rust-e2e.ps1 -RequireGui.
2. Observe harness_webview_left_click_px_background. It resolves the fixture's
   Increment button and verifies a CDP click and a foreground pixel click before
   testing the background pixel route.
3. If a UIA desktop-enumeration call times out immediately beforehand, inspect
   the background action and the application-owned counter.

Observed once in the linked run. The same test passed in the preceding candidate
run. The provider stall is intermittent; this is not a claim of deterministic
reproduction on every machine.

Expected behavior

The declared WebView2 background-click case must increment the counter without
changing foreground focus, z-order, or the primary cursor. When UIA is unavailable,
the implementation should preserve that distinction rather than treating a
provider timeout as an ordinary hit-test miss. It must not silently take over
the foreground or replay an action of uncertain delivery.

Actual behavior

The initial two clicks reach counter=2. The background call leaves it at 2
instead of reaching 3. Its recorded action facts are:

{
  "result_error": false,
  "effect": "unverifiable",
  "route": "synthetic_events",
  "transport": "windows_post_message"
}

Before the call, the log reports a 2000 ms UIA enumeration timeout, followed by
the provider returning and a 30000 ms cooldown. The complete case takes 15.561 s.
The following WebView2 page-roundtrip case passes, so the fixture remains live.
The action does not claim a confirmed application effect; this report concerns
the unavailable route and failed behavioral expectation.

Environment

• Driver source version: 0.23.2, candidate
  1133a06e4f205cf80188a7ac9e41102f37611fea.
• GitHub-hosted windows-latest, x86_64, with the canonical interactive-desktop
  preflight passing.
• Repository WebView2 fixture; no external application or user data.

Evidence

• Failing run, attempt 1,
  rust-windows-native artifact: windows-webview2-left-click-px-background in
  results.jsonl, Windows-web-harnesses.log, and its linked trajectory.
• Preceding passing run
  tested 315f15b8a4ce82736fe308850d8e4b6dfb8efdfb.
• The intervening diff does not change the WebView2 test, UIA deadline/gate, or
  input dispatch; the Windows product diff adds snapshot action metadata.

Suspected cause and acceptance

uia/windows_enum.rs shares a single-flight gate between desktop enumeration
and target hit-test Invoke. try_invoke_in_window_at_point converts Busy/Timeout
to false; ClickTool treats that as a normal miss and may use PostMessage.
The code documents that this route may not reach WebView2 content. The retained
trace matches this chain, but a controlled provider-stall regression is needed
to prove it deterministically.

Add focused coverage for Busy/Timeout versus a genuine non-invokable target.
Preserve the unchanged canonical fixture-state, focus, z-order, cursor, and
input-leak oracles. Do not resolve this by skipping the cell or changing the
expected counter. Any delivery-policy change should also verify ordinary Win32
controls whose message fallback is valid.

Related: #2201 tracks standalone Chrome raw background clicks and sentinel blur.
This report concerns the repository WebView2 fixture and UIA-provider cooldown;
no focus-steal result is established by this failed case.

Submission checks

• I searched for duplicate issues and active pull requests.
• This issue describes a single problem.
• I removed credentials, private data, sensitive screenshots, and
  vulnerability details from this public report.