fix: await MCP server initialization before returning McpHub instance

[daniel-lxs]

Summary

• MCP tools were unavailable on the first task turn when started via IPC because McpHub's constructor fired initializeGlobalMcpServers() and initializeProjectMcpServers() as fire-and-forget async calls. McpServerManager.getInstance() returned a hub with servers still in "connecting" state.
• Store the combined initialization promise in McpHub and expose waitUntilReady(), then await it in McpServerManager.getInstance() so the hub is only returned after all servers have connected or timed out.
• Individual server timeouts are preserved — no risk of blocking indefinitely.

Test plan

• Verified all 47 existing McpHub.spec.ts tests pass
• Verified no TypeScript errors in roo-cline package
• Verify MCP tools appear in the system prompt on the very first API call of a new task started via IPC
• Verify that if an MCP server fails to connect, the task still starts after the server's configured timeout

🤖 Generated with Claude Code

Start a new Roo Code Cloud session on this branch

[roomote]

Rooviewer   See task

All previously flagged issues have been resolved. No new issues found.

• Race condition in McpServerManager.getInstance(): this.instance is set before waitUntilReady() completes, so concurrent callers bypass the wait and receive a not-yet-ready hub

Previous reviews

• 2e67d77: Review #1

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote]

Fixaroo   See task

Fixed the race condition by assigning this.instance only after waitUntilReady() resolves. All local checks passed (lint, type-check, 47 McpHub tests).

_{View commit | Revert commit}