[iamnbutler]

Fixes #226
Fixes #229
Refs #5

#226: keys into a list in a window that isn't key

Cause: there were two layers.

• A SwiftUI List / onDeleteCommand drops a background key unless its window is key.
• A background (Accessibility) click on a row selects it but doesn't make the list first responder. The window's focused element is the window itself, so AppKit drops Delete and Return.

Fix:

• desktop_key makes an inactive app's window key first. It uses the same SkyLight activation and title-bar click that background paste uses, so the app isn't brought forward. The result reports key_window: made_key | already_key | not_key.
• When the window itself holds focus, desktop_key focuses the window's one list, table or outline with a selected row (list_focused). Focus never leaves the window.
• The result is now unknown, with KEY_WINDOW_UNAVAILABLE or KEY_NO_FOCUSED_VIEW, when neither works.
• A second preparation soon after the first no longer clicks the title bar again; macOS read that as a title-bar double-click and zoomed the window.

Live check (native2/fixture/keysfix.swift, app inactive, user's frontmost app unchanged):

• SwiftUI List Backspace: completed, made_key, list_focused, and the fixture logged list deleted ["two"]. Before the fix it was completed with nothing deleted.
• AppKit table: Backspace deleted the row; down then Return renamed (already_key).
• A list window that isn't the app's focused window is still refused, with nothing sent.

#229: Cloud Shell xterm paste

Cause:

• xterm's helper textarea clears itself after every input, so a paste into it can never be read back. It was reported unknown, and the text stayed on the clipboard.
• Typing reaches xterm at once, including in a cross-origin iframe in inactive Chrome. A test page with xterm 5.5.0 logged each character from onData.
• So the late run in Cloud Shell was most likely its stalled backend replaying buffered input after "Terminal tabs have been recovered". This is inferred; I didn't reproduce it against Cloud Shell itself.

Fix:

• desktop_insert into a web terminal's input (xterm class, or "Terminal input" on a web field) types instead of pasting.
• route: "paste" there is refused with PASTE_UNVERIFIABLE_RECEIVER; nothing is written to the clipboard.
• Typed text is unknown with web_terminal: true, and a hint to check with ocr and press Return with desktop_key, never to retype.

Live check (webfix terminal input): paste refused; typing gave web_terminal and the page received e-c-h-o-space-h-i; a newline was refused. In Chrome, xterm in a cross-origin iframe received " xt3". Chrome doesn't name xterm's textarea as focused there, so that result is the generic window_focus unknown.

#5: WebKit page fields and background Command-V (partly)

Findings:

• The fields were missing on the first inspect because WebKit builds a WKWebView's Accessibility tree only when first asked. The first read finds only an AXGroup; the AXWebArea appears under it milliseconds later. It wasn't the element cap.
• A WKWebView app names no AXFocusedUIElement, so background keys were refused. The page's field reports AXFocused itself.
• Edit › Paste is disabled (AXEnabled false) in a background WebKit app before preparation.
• After the window is made key it is enabled, and an Accessibility press of it pastes, but only with a page field focused. With no field focused it stays disabled even in the key window.

Fix:

• Inspect re-reads for up to 2 s until the web area appears. Each group is waited on once.
• Focus checks fall back to the deepest focused element under the web area.
• Inspect names that field as the focused element when the web area and scroll area also report focus.

Live check (native2/fixture/webfix.swift):

• The first inspect lists all 4 fields.
• Background Cmd+V pasted "BG-CMD-V" into the textarea; the page's paste event had text/plain.

Not done:

• The user's Safari wasn't tested, by instruction. Safari page fields are the part of WebKit: background Command-V, and Safari page fields missing from Accessibility #5 still open.
• desktop_insert route: "paste" into a web <input> is still refused before sending, because its text can't be read back. That is the existing behaviour, unchanged.

Fixtures

native2/fixture/keysfix.swift and native2/fixture/webfix.swift; build commands are in their headers.

Tests

• swift test --package-path native2: passes, including the new KeyboardRouteTests.
• npm run check: passes.
• npm test: passes.