Support non-Claude orchestrators for collaborative sessions (mountable fleet MCP)

[saucam]

Summary

Support non-Claude orchestrators for collaborative sessions.

Follow-up to the collaborative-session design (docs/collaborative-session-design.md, PR #244). v1 pins the orchestrator role to the Claude provider because the fleet tool surface is built as an in-process Claude-SDK MCP server (createSdkMcpServer in src/daemon/fleet.ts), and session-manager.ts warns that a non-Claude conductor "will chat but cannot see the fleet." Worker roles (search / reasoning / architecture / review) can already run on any backend in v1 — this issue is specifically about letting the orchestrator run on gemini / openai / codex / pi.

Why it's tractable

The codex, gemini, and openai providers already parse and gate mcp__* tool calls (codex/index.ts elicitation via mcpServer/elicitation/request, gemini/index.ts, openai/index.ts). The gap is only that the fleet + blackboard tools are an in-process Claude-SDK object rather than a mountable MCP server.

The design's D1 decision is to build the fleet + blackboard tool surface as a mountable MCP server from day one (stdio/registry, reusing the existing MCP-registry mounter), so this becomes a mount-config change rather than a rewrite.

Scope

• Expose the fleet + blackboard tools as a mountable MCP server (not the in-process Claude-SDK object).
• Mount it for non-Claude orchestrator sessions via the existing MCP-registry mounter.
• Cross-provider fleet-tool test matrix (elicitation-gating per backend; approval flow parity).
• Remove / soften the session-manager.ts "cannot see the fleet" warning once a backend is verified.
• Surface any-backend orchestrator selection in the create-time Collaborative picker.

Out of scope

Full Cedar/Shield governance of orchestrator delegation (tracked with the P6 governance milestone).