fix: wait for the restored pointer before calling a modifier click's cleanup unverified

[iamnbutler]

Fixes #127.

After a foreground modifier click, CursorRestorationOwnership.restore moves the pointer back. It does that by posting a mouse-moved event to the HID event tap, then reads the location straight away. The window server applies posted events after the post returns, so that read still finds the click point. As a result, every Command-click and Shift-click failed its cleanup with DESKTOP_ACTION_FAILED and "The physical cursor restoration was dispatched but could not be verified". I saw it 4 of 4 times on a Finder fixture with the installed 0.13.1, and in the #77 live checks.

New peekaboo-cursor-readback.patch:

• After the move, the location is read up to 20 times, 10 ms apart. Restoration counts as soon as the read finds the original point.
• The ownership checks before the move are unchanged.
• A pointer that never arrives is still an indeterminate failure, now after at most about 190 ms.
• The tests cover arrival on the first, fifth and last read, and a pointer that never arrives.

Modifier clicks stay unknown with DESKTOP_ACTION_UNVERIFIED, because their effect can't be confirmed. Only the false cleanup failure goes away.

Verification

• The Peekaboo tests ran in a scratch checkout at the pinned revision with main's patch stack: ForegroundModifierClick* 54 pass, and UIAutomationServiceModifierClickSnapshotTests|SyntheticInputDriver 22 pass.
• npm run build:native succeeds, npm test passes 75, and npm run check is clean.
• Not verified live yet. The installed app doesn't have the patch, and the dev app is waiting for its grants. The live check to run is --only 77: Command-click and Shift-click should show cursor_restoration: "restored".