Restore hidden input delivery when an owned background lease is out of sync #355

Context

PR #311 makes an owned background-execution lease safe when the target still reports document.visibilityState === "hidden": the input tool returns input_not_ready before dispatch instead of reporting a click that may not be delivered. This preserves the safety requirement from #242, but the input is not delivered in this edge case.

BackgroundExecution.has(sessionId, tabId) reports desired ownership. Its applied cache can still match the debugger attachment even if the actual Emulation.setFocusEmulationEnabled override was turned off outside that cache. A normal synchronize() call then skips reapplying the override.

Requested improvement

When a controlled input tool samples hidden while the session owns a persistent background lease, attempt to restore the override through BackgroundExecution itself, then wait for a renderer frame before dispatching. Do not enable or disable focus emulation directly from withInputReady, and do not activate the user's browser window. If readiness still cannot be established, keep returning input_not_ready with no input dispatched.

Acceptance criteria

• A dispatcher-level test simulates an owned lease whose applied focus override was lost. A hidden-page click recovers through the lease owner, reaches the page, and leaves the override enabled for the next tool.
• A real-browser check covers a minimized --no-focus Agent Window, ideally on Windows 11 at DPR 1.5 as in bsk click silently reports success while delivering no input when the Agent Window is in the background (--no-focus) #242. Turn off the override from the extension service worker to reproduce the stale applied-cache state, then verify that the click event reaches the page and the lease remains active.
• Failed recovery reports input_not_ready before dispatch, rather than a successful click result.

Related: #242 and PR #311.