feat(mcp): expose fork and merge-back commands

[juliusmarminge]

Part 8/16 of the shared-core and MCP stack. Based on #10557. Next: #10559.

Expose the existing fork and merge-back commands plus transfer status. The caller supplies an existing stable source point; orchestration owns lineage, persistence and provider transfer execution.

Each invocation generates a new command. No additional clientRequestId protocol, transfer journal or provider implementation. Merge targets remain in the calling project.

MCP-only rebuild of #8696, #8697, preserving attribution to Julius Marminge's original work. Original branches remain available for separate service follow-ups.

Validation: The composed stack passes 94 tests across 12 focused files, including shared core MCP and real MCP/V2 integration, attachment intake, project RPC/service contracts, and client model command selection. Server/contracts/shared/client-runtime typechecks and targeted format/lint/diff checks pass. New behavior coverage lives with the shared operation; no per-tool mock suite was added. Current-head CI is shown below.

Layer size: 4 files, +99/-1. No domain-service production implementation or documentation files change in this MCP layer.

Prepared with Codex in the OpenAI agent runtime.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds new MCP tools that let agents create thread forks and merge context back into related threads, with persistent orchestration and transfer-state effects. The operations are explicitly destructive and the new MCP handlers lack dedicated tests in this change, so the expanded workflow warrants human review.

No code changes detected at e3e71c7. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for e3e71c7.

This comment will update automatically after the next completed run.