Cherry-picked upstream PRs

This vendored copy is based on the tag in .vendored-from (cua-driver-rs-v0.7.0), plus a small set of upstream trycua/cua pull requests applied as ordinary commits on top of the base snapshot.

Upstream PR	Fix	Status	Touches
trycua/cua#2036	retry daemon socket writes on `EAGAIN`/`EWOULDBLOCK` instead of failing fatally	upstream-merged post-0.7.0 tag; re-injected here, remove when syncing to a ref that includes it	`cua-driver-core` (socket_io), `cua-driver` (serve.rs)
trycua/cua#2021	`list_windows` includes empty-/null-title top-level windows; `resolve_uwp_host_window` for UWP apps	open (draft)	`platform-windows`

Retired patches (subsumed by 0.7.0)

Upstream PR	Fix	Why retired
trycua/cua#2025	X11 synthetic click false-success	Superseded by 0.7.0 honest-verification system
trycua/cua#2035	`start_session` revive idle-reaped session	Superseded by 0.7.0 `revive_session`/loud-reject/`is_session_lifecycle_tool`

When you sync to a newer upstream ref

scripts/sync-from-upstream.sh diffs .vendored-from→<new-ref>. If <new-ref> is at or past the commit where one of these PRs merged, that PR's changes are already in the upstream delta, so:

The hunks will collide with the cherry-picked commit (expect .rej on the files above), and
Once reconciled, remove the row from the active table — it's no longer a local patch, it's part of the base.

If <new-ref> is still before a PR merges, that row stays; the cherry-pick keeps carrying the fix.