fix(cua-driver): unify native action scheduling

[injaneity]

What changed

Cua Driver used separate code to coordinate desktop actions and text entry. It also kept its own list of tools for each path, so a new tool could miss the right checks.

This pull request replaces that code with one small scheduler. It now:

• runs desktop actions one at a time;
• prevents two text operations from writing to the same process at once;
• applies the same text protection to type_text and type_text_chars; and
• keeps the action and the post-action window check from feat(cua-driver): add target-scoped post-action rediscovery #3373 together.

It also removes the old desktop lock, text-process set, custom cleanup guard, and duplicate tool list.

There are no browser or public API changes.

Refs #3373

Checks

Candidate 4e7bc5b20f567217034b4d0a50d542d67bd65eb0:

• formatting and diff checks pass;
• focused tests cover waiting, refusal, cancellation, cleanup, and tool selection; and
• all 23 reported CI checks pass.

This branch needs to be rebased onto the latest #3373 before merge.

[kvnloo]

I think the unified scheduler still has one lifecycle hole that matters for the invariant it is trying to establish: the lease lifetime is tied to the async dispatch future, not necessarily to the native work it admitted.

ToolRegistry acquires _desktop_action_lease, then does:

let mut result = tool.invoke(args.clone()).await;
...
drop(_desktop_action_lease);

That is correct on normal completion. But many platform actions run irreversible work through tokio::task::spawn_blocking(...).await — macOS drag is a clear example, and the keyboard/platform paths have the same shape.

Tokio cannot cancel a spawn_blocking closure once it has started. If the outer tool future is dropped/cancelled after native entry:

1. tool.invoke(...).await is abandoned;
2. _desktop_action_lease is dropped with the dispatch future;
3. the native blocking closure can keep delivering input;
4. a second action can now acquire PhysicalDesktop and overlap the still-running first mutation.

So the scheduler can report the lane free while the resource it represents is still physically in use.

The current scheduler regression:

cancelled_waiter_does_not_keep_or_poison_a_resource

covers the opposite boundary — cancellation before acquisition — and is useful, but it does not prove cancellation after acquisition/native entry.

This appears to compose directly with #3796 rather than requiring a second cancellation design. I would record the scheduler invariant as:

A native-action lease is released only when the admitted native mutation has reached a boundary that can no longer affect that resource. Dropping the caller's waiter is not such a boundary.

For this PR, the smallest safe choices seem to be either:

• explicitly make [RFC]: cooperative cancellation of one in-flight driver call, with owned native cleanup #3796's owned/cooperative blocking primitive a prerequisite for claiming cancellation-safe scheduling; or
• keep the scheduler refactor but document that cancellation-after-native-entry remains an existing unsupported gap and add a red/fault-injection test that demonstrates it, rather than treating RAII on the outer future as complete ownership.

The discriminating regression is straightforward:

1. acquire the physical desktop lease;
2. start a blocking action behind a barrier and prove native entry;
3. cancel/drop the outer async invocation;
4. attempt a second desktop action before releasing the barrier;
5. require the second action not to enter;
6. release the first native worker, then require the lane becomes available exactly once.

A held-input variant (drag/key-down) is even stronger because it observes the actual resource rather than only the scheduler.

The conceptual distinction is important: cancelled waiter != completed owner. The scheduler should model the lifetime of the effect it serializes, not only the lifetime of the task that requested it.