fix(click): bound boundingBox() in mouse-sequence fallback to prevent 30s timeout 500s

[leoneparise]

Problem

When a /tabs/:tabId/click request hits the mouse-sequence fallback and the target element has detached (page changed between snapshot and click — common on SPAs like LinkedIn search results), locator.boundingBox() is called with no timeout. Playwright waits its default 30s for the element to resolve, which blows the entire handler budget:

{"level":"warn","msg":"click timeout, trying mouse sequence"}
... 27s of silence ...
{"level":"error","msg":"click failed","error":"action timed out after 30000ms"}
{"level":"error","msg":"internal error","error":"action timed out after 30000ms","stack":"Error: action timed out after 30000ms\n    at Timeout._onTimeout (file:///app/server.js:485:31)"}
{"level":"info","msg":"res","status":500,"ms":30938}

Two compounding issues:

1. The client waits the full 30s and gets an opaque 500.
2. The generic action timed out after 30000ms message is matched by isTimeoutError(), and since click is in NAVIGATION_TIMEOUT_ACTIONS, handleRouteError() destroys the whole user session (fresh BrowserContext + proxy) — losing every other live tab — over what is really just a stale ref.

Observed in production logs (v1.11.2) during a LinkedIn people-search batch: two such 500s in one run, each costing ~31s and killing the session of a concurrently-used tab.

Fix

In dispatchMouseSequence:

• boundingBox() is now bounded to min(3000ms, remaining handler budget), floored at 500ms.
• On timeout it throws a 422 Element not actionable error that (a) returns in ~3s instead of 30s, (b) deliberately avoids the timed out after phrase so isTimeoutError() doesn't nuke the session, and (c) tells the caller to snapshot + retry — which is exactly what the existing post-timeout refresh path recommends.

Tests

New tests/unit/clickBoundingBoxTimeout.test.js (7 tests):

• source contract: no bare boundingBox() calls remain in server.js; the call site uses bboxTimeout; the error carries statusCode = 422
• budget math: cap at 3s, pass-through under cap, 500ms floor
• error classification: new error is NOT a session-destroying timeout; documents that the old behavior WAS

node --check server.js passes; full unit suite: 661 passed, with the only failures (security.test.js, cookies.test.js) failing identically on clean master in my environment (real-browser spawn tests), i.e. pre-existing/environment-dependent.