[iamnbutler]

Closes the remaining item of #5: desktop_insert with route: "paste" (or the default route when a field is focused) into a web <input> was refused before anything was sent.

Cause

Two problems, both in Mac.pasteText:

1. It checked keyboard focus before making an inactive app's window key. A background WKWebView window that isn't key reports no focused window, so the check refused: "Exact-window keyboard focus is not on the target window". The window was made key only later, inside paste. Typing already prepares the window first (prepareKeys, Keys to a list in a non-key window return completed but never reach it #226/Keys reach a SwiftUI List and a WebKit page in the background; web terminals are typed into, never pasted #240).
2. The baseline and read-back (ReceiverState.read) required the app's AXFocusedUIElement to be the field. A WKWebView app names none. The page field reports AXFocused itself, which requireKeyboardFocus already handles through focusedWebElement (Keys reach a SwiftUI List and a WebKit page in the background; web terminals are typed into, never pasted #240).

Change

pasteText now calls prepareKeys before checking focus. prepareKeys makes the window key without moving focus between windows. The receiver read accepts the app's focused element, or else the focused page field in its focused window. The paste is then confirmed by the field's value and selection, as for native fields, and the clipboard is restored after it shows.

Checked

On the WKWebView fixture (native2/fixture/webfix.swift), through the standalone host built from this branch, relaunching the fixture each time so its window starts out not key:

• 3 cold runs × <input>, <textarea> and contenteditable composer: 9/9 completed, consumption: observed, clipboard_cleanup: restored. The page logged exactly one paste and one input per field.
• The default route (no route) into the <input>: completed, and the page logged the paste.
• Before the change: refused with "Exact-window keyboard focus is not on the target window at dispatch".
• swift test --package-path native2 passes.

One attempt right after my first edit was still refused with the focus message. I couldn't reproduce it in the cold runs above. If it recurs, the likely cause is prepareKeys' 0.5 s wait for the page to give focus back to the field after the window becomes key. Safari wasn't touched.

🤖 Generated with Claude Code