Add an optional local control API with an MCP adapter

[TyceHerrman]

Problem

Tart's daemonless CLI is a useful default, but integrations that manage VM lifecycles currently need to spawn and supervise CLI processes, parse command output, and independently track long-running operations.

Structured JSON output helps with individual commands, but it does not provide a stable control surface for tools that need to list, create, clone, run, stop, and monitor VMs. It also means every editor, agent, or orchestrator has to build its own Tart wrapper.

This request is related to the daemonless design discussed in #303 and discussion #449, but it does not require changing the default CLI behavior.

Proposal

Provide an optional local service backed by Tart's existing storage, locking, and lifecycle code. For example:

tart serve --socket ~/.tart/tart.sock

The initial API could expose:

• version and host status
• VM list and configuration
• create, clone, run, stop, and delete operations
• operation status and structured errors for long-running work

HTTP/JSON over a Unix-domain socket would make the service easy to integrate without exposing it to the network. A later tart mcp command could adapt the same API into a small set of MCP tools instead of maintaining a second implementation.

Safety and compatibility

• Keep Tart daemonless unless the user explicitly starts the service.
• Listen on a local Unix-domain socket by default; do not enable TCP implicitly.
• Preserve the current CLI and JSON output.
• Do not expose registry credentials or guest secrets through the API.
• Version the API so external integrations can detect incompatible changes.

Alternatives considered

• Spawning CLI commands works for simple cases but leaves process supervision, progress, cancellation, and error normalization to every consumer.
• Orchard provides higher-level orchestration, but it is not a lightweight local Tart control API.
• A third-party MCP wrapper would still need a stable underlying interface and would otherwise depend on CLI output details.

Would an opt-in local control service fit Tart's intended scope if the normal CLI remains daemonless?