Let an MCP integration raise its tool timeout

[sjdonado]

Summary

Every upstream MCP tool call runs under a fixed 60s active-work deadline (MCP_ACTIVE_WORK_TIMEOUT_MS), and nothing reachable from an MCP host can change it. Servers whose tools legitimately take longer, for example one that drives a signed-in browser where a single call takes 60 to 90s, fail at the one-minute mark every time.

This adds an optional toolTimeoutMs to both MCP integration configs (stdio and remote) and to the addServer inputs. The invoke path passes it to makeActiveWorkDeadline, which already took a timeout argument but was always called without one. Absent, zero, negative or non-finite values keep today's 60s, and time spent waiting on an elicitation still pauses the deadline as before (#1953).

#1988 is related but covers a different caller: it threads per-call InvokeOptions for SDK users. Calls that arrive over MCP (execute from an agent) never carry those options, so the deadline has to live on the integration.

Verification

• bun run format:check
• bun run lint
• bun run typecheck, scoped to ...@executor-js/plugin-mcp: 39 tasks successful
• bun run test, scoped to ...@executor-js/plugin-mcp without e2e: 7 tasks successful. In @executor-js/plugin-mcp that is 312 passed, 29 skipped
• e2e: none covers per-integration timeouts; the change is config plumbing with no UI

New cases in packages/plugins/mcp/src/sdk/invoke.test.ts: a call with activeWorkTimeoutMs at twice the default is still running after 60s and aborts at 120s, and unusable values fall back to the default. The first fails without the plumbing in invoke.ts.

Checklist

• Added a changeset.
• Added tests for the new behaviour.
• No secrets, credentials, or private data in the diff.

Thanks for Executor; the local daemon plus native elicitation is exactly what we needed to put a whole set of stdio servers behind one endpoint.