While dogfooding the first native-action slice of #8, a real Accessibility click can change Ace's UI and then fail to return its native result. The host times out after 30 seconds and correctly reports an uncertain outcome.

Observed in a signed development build with embedded Peekaboo 4.8.0 and all required permissions granted:

1. Inspect Ace's exact window and use the returned snapshot and literal control ID. 2. Click **Rename** in the channel rename dialog. The dialog closes and the channel name is persisted, but the native client times out. 3. The same occurs when clicking **Toggle details sidebar**, whose control remains present.

Field replacement and the exact-window basic-key path complete normally. This is not a reason to retry the click: its effect already happened.

Investigation points to the embedded native Accessibility press path. Peekaboo performs the press synchronously on its main actor and also reads properties of the target after pressing it. Those reads are especially problematic when the action removes its own control. We need to verify the precise blocking point and fix native completion without weakening application/window/control binding or declaring an uncertain action successful.

Acceptance:

- Ordinary Ace button clicks return promptly with their real native outcome and a fresh observation when available. - Controls that disappear after activation do not stall native completion. - Stop/disconnect still cancel pending work; desktop coordination remains held until any in-flight native operation actually finishes. - Lost or uncertain responses remain unsafe to replay, with real-runtime coverage.

Blocks reliable button-click dogfooding for #8.