Wait for preview guest readiness before dispatching agent input #35407

Problem

Agent input can reach a hidden preview guest before the client restores it for painting. In the Windows reproduction in #17483, preview_click on a tab opened with open: false reports success, but the page receives no pointer events.

The painting lease reduces the race for agent-owned tabs, but publishing a painting request does not confirm that the client has restored the guest. A tab attached before the turn and not previously used by the agent can receive its first command before restoration. A command can also arrive before the turn announcement, when the turn-based lease has not yet requested painting.

Required change

Add a client readiness acknowledgment and coordinate it across desktop, server, and web. Ensure agent input waits until the client has restored the guest before dispatch. Request painting for the initial command even if it arrives before the turn announcement. Handle canceled or detached guests without leaving input waiting indefinitely.

Affected areas include apps/desktop/src/preview/DesktopBrowserHost.ts, the preview painting and command protocol, and the web client that restores the guest.

Acceptance criteria

• A first agent input to a hidden, previously unused tab is not dispatched before the client acknowledges readiness.
• Input is handled correctly when the command arrives before the turn announcement, and when the turn is announced first.
• Regression tests exercise delayed readiness and verify that a click reaches the page after restoration. Cover cancellation or detachment while waiting.
• Existing active-turn painting and capture/stream behavior continue to work.

Maintainer decision

Should the acknowledgment and its regression tests land in PR #34681 or in a separate change? The acknowledgment requires a protocol change across desktop, server, and web.

Related issue: #17483
Pull request: #34681
Review thread: #34681 (comment)
Requested by: @joei4cm