feat: stdio / local MCP servers (governed)

[arthurpanhku]

Why (roadmap: Next)

Governed MCP v1 (docs/GOVERNED-MCP.md) covers remote Streamable HTTP servers. Local stdio servers complete the story — many MCP tools run locally, and stdio avoids network egress entirely.

Sketch

• Spawn the server as a child process through runGovernedProcess (sandbox + policy) — never a bare spawn (see the governance rules in CONTRIBUTING).
• Same JSON-RPC methods as src/mcp/client.ts but over stdin/stdout framing.
• Same governed mapping: mcp__<server>__<tool>, policy admission via mcp.allow, audit mcp_request per call, annotation-derived access tiers.
• Config: { id, command, args, enabled } alongside remote servers.

Open questions

• Sandbox profile for a long-lived child (network-denied by default? policy knob?)
• Lifecycle: per-run vs per-session process reuse; kill on run end.

[shivasb42]

How I plan to solve this

Remote HTTP MCP already works. This adds local stdio MCP.

Problem: Most local MCP servers (npx @modelcontextprotocol/server-*) only talk over stdin/stdout, not HTTP. DvalinCode can't use them today.

Solution:

Extend mcp.servers config with local entries: { id, command, args, enabled } (remote keeps { id, url, headers, enabled }).
Add a stdio MCP client — spawn the process, send/receive newline JSON-RPC (initialize, tools/list, tools/call).
Spawn through a governed subprocess helper (sandbox + policy), not bare spawn().
Reuse existing wiring: mcp____, mcp.allow, mcp_request audit, annotation → access tier.
Start one process per session, kill on session end.
Not changing: remote HTTP path, tool names, policy model.

v1 defaults: per-session lifecycle, sandbox like shell, audit host = stdio:.

Can implement once this approach looks good.