fix: separate screenshot response timeout from IPC connect timeout

[MagMueller]

What Problem This Solves

Page.captureScreenshot can take longer than the 5-second local IPC connection budget when the daemon is attached to a remote Cloud browser. The connected socket currently reuses that 5-second value for the entire screenshot response, causing recoverable screenshot calls to time out.

Why This Change Was Made

Keep the 5-second IPC connect and default response budget, but give screenshot responses a bounded 60-second budget. Timeout errors remain generic and do not expose endpoint details.

User Impact

Remote viewport and full-page screenshots can complete without weakening the timeout applied to ordinary Browser Harness commands.

Evidence

• Diff is limited to 2 files: the helper implementation and focused tests.
• uv run --with pytest pytest -q tests/unit/test_helpers.py: 24 passed.
• git diff --check: passed.
• In the final OpenClaw evaluation head, the earlier screenshot IPC timeout signature remained at zero.

---

Summary by cubic

Separates the IPC connect timeout from the response timeout so screenshots don’t inherit the 5s budget. Previously a single 5s timeout covered connect and response; now connect stays 5s and default responses stay 5s, while Page.captureScreenshot uses a 60s response budget without weakening other commands or exposing endpoint details.

• Introduces IPC_CONNECT_TIMEOUT_SECONDS (5s), DEFAULT_IPC_RESPONSE_TIMEOUT_SECONDS (5s), and SCREENSHOT_IPC_RESPONSE_TIMEOUT_SECONDS (60s); _send sets per-call socket timeouts and raises _IPCResponseTimeout on response timeouts.
• cdp accepts _response_timeout; capture_screenshot uses the 60s budget and converts screenshot timeouts into a contextual RuntimeError. Tests cover the new budgets and error message.

^{Written for commit 742d3ed. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}