fix(acp): route Factory Droid through direct ACP

[specter119]

Related issue

Closes #366

Problem / pressure

Factory Droid's acp-daemon mode fails during ACP session/new whenever Lody includes a stdio MCP server. The daemon injects an unsupported --mcp-servers argument into its inner Droid process, which exits with code 1 and is surfaced as -32603 Internal error. This blocks the normal MCP-enabled Factory Droid workflow.

Summary

• Exclude the broken remote Factory Droid registry entry.
• Add a pinned droid@0.211.0 npx registry entry that launches direct acp with auto-update disabled.
• Add a regression test covering the pinned version, distribution, launch arguments, and capability source version.

Before / after

Before	After
Factory Droid used droid@0.208.2 exec --output-format acp-daemon; with a non-empty session/new.mcpServers, the daemon launched a child with unsupported --mcp-servers arguments and ACP returned -32603.	Lody uses pinned droid@0.211.0 exec --output-format acp; MCP configuration remains in the ACP session/new.mcpServers request and session initialization succeeds.

Test plan

• Factory Droid ACP ablation with a synthetic stdio MCP server: acp-daemon failed and direct acp succeeded on both Droid 0.208.2 and 0.211.0.
• apps/cli/tests/agent-setting.test.ts: 30 tests passed.
• tsgo --noEmit: passed.
• node scripts/check-public-boundary.mjs: passed.
• git diff --check: passed.
• PR body validation with .github/scripts/check-pr-body.mjs: passed.

Context handoff

Instructions for reviewing agents

• Review focus: Check the generated and source ACP registry entries plus the agent-setting regression test, especially direct-ACP arguments, version pinning, and MCP capability behavior.
• Decisions to challenge: Confirm that bypassing acp-daemon is the correct compatibility boundary and that keeping MCP in session/new.mcpServers preserves the intended protocol contract.
• Plausible failures / evidence gaps: Future Droid releases may change ACP flags, and CI does not run a live Droid/MCP integration; the reported failure was reproduced locally with synthetic stdio MCP input.

Authoring context

• User goal / directives: Restore reliable Factory Droid ACP sessions in Lody when stdio MCP servers are selected, and provide an upstream contribution that documents the failure.
• Constraints / non-goals: Keep the fix within Lody's public ACP registry and tests; do not patch Factory Droid, add private dependencies, or include private transcripts, credentials, or service data.
• Risk-bearing decisions: Pin Droid 0.211.0, disable its auto-update path, and select direct acp so Lody does not enter the daemon's unsupported child-argument bridge.
• Destructive or irreversible behavior: None. The change affects agent process selection and registry metadata only; it performs no data migration, deletion, overwrite, or runtime rollback.
• Deliberately not done or tested: Factory Droid itself was not patched; no live authenticated provider or private MCP service was used. The integration reproduction used a synthetic stdio MCP server.
• Unknowns / confidence: Confidence is high because child launch tracing and a version/mode ablation isolated the unsupported --mcp-servers argument. The remaining uncertainty is future compatibility if Droid changes its ACP CLI contract.