[Fix] Prevent Fast integration discovery from holding turns

[daniel-lxs]

What

• serve the last known-good Fast integration tool catalog immediately while an expired cache entry refreshes in the background
• bound first-time MCP tool discovery to 10 seconds so an unavailable deployment integration cannot hold a Fast conversation turn indefinitely
• bound native Fast integration calls to 60 seconds and return the timeout through the normal tool-failure path
• abort and close the underlying streamable-HTTP transport when either timeout fires
• retain stale catalog entries after a failed refresh and retry discovery later

Why

Fast discovers enabled deployment integrations before entering its OpenCode prompt. The tool catalog cache previously refreshed synchronously after five minutes, and MCP initialization/tool discovery had no timeout. A nonresponsive integration could therefore leave the Fast turn and its conversation lock open indefinitely, preventing later chat turns and child lifecycle delivery.

Validation

• regression: an expired catalog serves stale tools while a refresh never settles
• regression: first-time discovery times out without poisoning the cache
• regression: an integration call timeout is recorded in the durable audit
• regression: cancellation aborts a nonresponsive MCP initialization request and closes its connection
• cloud-agents suite: 99 files, 770 tests passed
• pnpm format:check
• pnpm lint:fast
• pnpm check-types:fast
• pnpm knip

[roomote-community]

No new code issues found. See task

• Timeout races leave non-cancelled MCP requests alive, causing recurring stale refreshes to accumulate transports (packages/cloud-agents/src/server/fast-agent/fast-agent-integration-broker.ts:83).

_{Reviewed 3d2fa5}