Give remote-CDP actionability probes the full remaining action budget

[LawyZheng]

Problem

On the connect_over_cdp() remote-attach path, click(), select_option(), and
fill() could time out prematurely — aborting after roughly 0.3–0.4 s even though the
caller's action deadline (default 30 s) was still far off.

The Locator actionability/state polling loops capped each individual CDP probe at a fixed
1000 ms. A single probe issues several CDP round trips; over a high-latency remote
transport those round trips can exceed 1000 ms, so every probe hit its per-probe cap and
raised TimeoutError. The _wait_for_single and _wait_for_fill_ready loops did not
catch that error at all; the fill-apply loop caught only the generic Error and re-raised
the TimeoutError (since TimeoutError subclasses Error). Either way the probe timeout
propagated out and aborted the whole action long before the real deadline.

Fix

• Budget each probe with the full remaining action time instead of a small fixed cap,
  via the _actionability_probe_timeout helper.
• Treat a per-probe TimeoutError as transient — keep polling until the outer action
  deadline rather than aborting (matching Playwright's behavior).
• Applied uniformly to the four sibling loops: _wait_for_single, _wait_for_fill_ready,
  the fill-apply loop, and the select-apply loop. The fill-apply loop now catches
  TimeoutError before the generic Error handler; the select-apply loop already
  caught it.
• All four loops surface owner unavailability (page/context/browser closed or crashed)
  immediately on a probe timeout instead of masking it: the two wait loops re-check the
  owner at the top of each iteration, and the fill/select-apply loops call
  _raise_if_owner_unavailable in their TimeoutError handlers.

Polling cadence is still driven by _sleep_until_next_poll, so widening the per-probe
bound does not busy-loop. For an infinite wait (timeout<=0) the probe keeps a bounded
1000 ms cadence so owner-availability and locator handlers are still re-checked
periodically.

The change is pure Python — no Rust/native changes, no timeout inflation of the outer
deadline, no vendor-specific behavior, no retries that bypass semantics, and no fallback
engine.

Tests

Call-count-driven regressions that force a first-probe TimeoutError on the real
affected loop paths (rather than only asserting the enlarged per-probe budget):

• test_fill_apply_loop_retries_transient_probe_timeout — the fill-apply _eval probe
  times out once, then the fill completes (RED before this commit: the transient timeout
  was re-raised).
• test_select_apply_loop_retries_transient_probe_timeout — the select-apply _eval
  probe times out once, then select_option() completes.
• test_wait_for_single_retries_transient_actionability_probe_timeout — the actionability
  _target_state probe times out once, then click() completes.
• test_fill_apply_loop_surfaces_outer_deadline_on_persistent_probe_timeout — a probe
  that always times out ends at the outer deadline with the loop's own editable-timeout
  message, bounded (no runaway busy-loop) (RED before: raw per-probe timeout surfaced).
• test_fill_apply_loop_propagates_owner_crash_on_probe_timeout — a page crash during a
  probe timeout raises Page crashed immediately instead of polling to the deadline
  (RED before: the raw probe timeout surfaced).

Validation status

Local browser-backed execution runs against the Playwright chrome-headless-shell build
(the full Chromium build does not expose its CDP endpoint on this host); under that build
all five regressions plus the surrounding fill/select/click/actionability suite pass, and
the RED→GREEN behavior was verified at head 72a5dbb. External reliability validation
over a real high-latency remote transport is stale after this commit and will be rerun by
Hermes; this stays Draft until that validation completes.

---

Update — head 6ecb956 (GIL-release + owner-consistency hardening)

Follow-up addressing the automated Critical GIL finding on this PR.

Supersedes the "pure Python — no Rust/native changes" note above: this commit includes
a one-line native change in src/lib.rs.

• locator_eval binding now releases the GIL explicitly via py.detach, matching its
  siblings click and locator_eval_handle. Note the GIL was already released for the
  blocking CDP round-trip one layer deeper — evaluate_locator → block_on →
  run_blocking_detached → run_detached wraps the work in
  Python::try_attach(|py| py.detach(..)) — so locator_eval did not actually
  monopolize the GIL in practice (verified: a pure-Python busy thread advances ~9M
  iterations while a ~0.75 s native locator_eval blocks). The change closes the
  binding-layer inconsistency and guards against future refactors. No 3–5 s probe cap was
  added.
• Guard test test_locator_eval_does_not_monopolize_gil_while_blocking locks in the
  GIL-release invariant.
• Owner-unavailability refinement: _wait_for_single and _wait_for_fill_ready now
  also call _raise_if_owner_unavailable inside their except TimeoutError block
  (before the deadline break), so a close that coincides with a probe timeout at the outer
  deadline raises the precise owner error instead of a generic actionability timeout —
  matching the fill/select-apply loops. New RED→GREEN test
  test_wait_for_single_propagates_owner_crash_when_probe_times_out_at_deadline.
  (_wait_for_fill_ready is currently unreferenced, so its mirrored edit is
  consistency-only.)

No transport or outer/probe timeout semantics changed.

Validation now stale at 6ecb956: the latest-head external actionability gate (20/20)
and the Codex rereview PASS predate this commit and must be re-run against the new head.
Stays Draft.

[LawyZheng]

Superseded by #96, which carries the identical reviewed changes on a public-safe branch.