fix(browser): retry Chrome MCP attach timeouts

[artemgetmann]

Summary

• Problem: existing-session Chrome MCP attach for user-live could fail around 19s with MCP error -32001: Request timed out even when callers passed a 60s browser timeout.
• Why it matters: the live Chrome approval loop needs the agent to wait through transient MCP attach/readiness timeouts instead of immediately telling the user to retry.
• What changed: added a named 60s existing-session attach budget, made status/availability honor it, and retry Chrome MCP attach/readiness -32001/request-timeout failures until the outer caller deadline expires.
• What did NOT change (scope boundary): no watchdog/Still working copy changes, no runtime restarts, no live Chrome or Telegram actions.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related fix(browser): extend managed start timeout #798

User-visible / Behavior Changes

Existing-session Chrome status/start follow-up checks now use a 60s attach budget, and Chrome MCP attach/readiness request timeouts are retried inside that budget before surfacing failure guidance.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local worktree tests only
• Model/provider: N/A
• Integration/channel (if any): browser tool / Chrome MCP existing-session path
• Relevant config (redacted): user-live existing-session profile class

Steps

1. Simulate Chrome MCP session attach returning MCP error -32001: Request timed out before the caller budget expires.
2. Simulate list_pages returning the same retryable timeout once before succeeding.
3. Exercise browser status/start timeout plumbing through client and tool tests.

Expected

• Retryable Chrome MCP attach/readiness timeouts do not fail before the outer 60s budget.

Actual

• Focused regression tests pass.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: focused Vitest browser MCP/client/tool coverage; scoped oxfmt; scoped oxlint; git diff --check.
• Edge cases checked: retryable session attach timeout, retryable list_pages timeout, availability preflight retry, caller timeout override propagation.
• What you did not verify: live Chrome attach, Telegram topic behavior, gateway runtime deployment.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR.
• Files/config to restore: src/browser/chrome-mcp.ts, src/browser/server-context.availability.ts, src/browser/client.ts, src/agents/tools/browser-tool.ts, related tests.
• Known bad symptoms reviewers should watch for: Chrome MCP attach loops longer than expected on non-retryable failures, or status calls taking up to the new 60s attach budget.

Risks and Mitigations

• Risk: retrying too broadly could mask real browser tool failures.
  • Mitigation: retry classifier is limited to Chrome MCP -32001 / request-timeout / attach-timeout messages; tool-level errors still fail normally.