fix(runtime): use main project root for MCP preflight on task retry (#515)

[kabaogluemre]

Summary

Fixes #515 — Test-DotbotMcpReadiness crashing with "MCP server exited or returned an empty response" when a task is retried after a failed squash-merge.

Root cause

The standalone preflight MCP process had DOTBOT_PROJECT_ROOT set to the worktree path. On task retry the worktree's .control junction can be stale — teardown/re-creation is not atomic — so the MCP server cannot resolve runtime.json (via <worktree>/.bot/.control/) and exits before the handshake even begins.

Two existing fixes don't cover this case:

• fix(mcp): increase preflight timeout and retry initialize #479 retries the MCP handshake — but here the process dies pre-handshake, so retrying has no effect.
• MCP server resolves DotbotProjectRoot to the worktree, silently discarding all agent-driven task-state transitions #356 fixed Resolve-DotbotProjectRoot via git rev-parse --git-common-dir — but that detection is bypassed whenever DOTBOT_PROJECT_ROOT is set, because Resolve-ProjectRoot.ps1 returns the env var value verbatim and skips git-based detection (see Resolve-ProjectRoot.ps1:30-49).

Fix

Add an optional -ProjectRoot parameter to Test-DotbotMcpReadiness. When supplied, it is used for DOTBOT_PROJECT_ROOT instead of the worktree path:

$psi.Environment['DOTBOT_PROJECT_ROOT'] = if ($ProjectRoot) { $ProjectRoot } else { $WorktreePath }

The call site now passes the main project root, which always has a stable .control/ directory:

$mcpReady = Test-DotbotMcpReadiness -WorktreePath $worktreePath -ProjectRoot $projectRoot

WorkingDirectory stays the worktree (work happens there); only task-state resolution is redirected to the main root — consistent with #356's intent. Backward compatible: callers that omit -ProjectRoot fall back to the previous worktree behaviour.

Closes #515

[carlospedreira]

@kabaogluemre this highlights a bigger concern with the root model around MCP. Right now, DOTBOT_PROJECT_ROOT seems to carry two meanings: the worktree where the agent should operate, and the stable project root where dotbot runtime/task state lives. This PR fixes the preflight path by pointing it at the stable root, but the actual provider MCP config and launch paths still point the MCP server at the worktree, so preflight and the real session can diverge.

I think we should make that split explicit instead of patching one caller. The agent cwd should stay as the worktree, but MCP state/runtime resolution should use a dedicated DOTBOT_STATE_ROOT. That would avoid relying on worktree .control links being valid during retry/teardown windows, and it would give us tests that cover the actual failure mode rather than only checking the preflight assignment.

[kabaogluemre]

@kabaogluemre this highlights a bigger concern with the root model around MCP. Right now, DOTBOT_PROJECT_ROOT seems to carry two meanings: the worktree where the agent should operate, and the stable project root where dotbot runtime/task state lives. This PR fixes the preflight path by pointing it at the stable root, but the actual provider MCP config and launch paths still point the MCP server at the worktree, so preflight and the real session can diverge.

I think we should make that split explicit instead of patching one caller. The agent cwd should stay as the worktree, but MCP state/runtime resolution should use a dedicated DOTBOT_STATE_ROOT. That would avoid relying on worktree .control links being valid during retry/teardown windows, and it would give us tests that cover the actual failure mode rather than only checking the preflight assignment.

@carlospedreira , thanks for your review, a dedicated DOTBOT_STATE_ROOT is the cleaner approach. Applied it across the resolver, all provider adapters, and the generated MCP configs, so preflight and the real session now share the same model. Also added tests for the actual resolver failure mode.