arch: add process/container isolation for MCP tool bridges #3229

Problem

AutoBot's MCP bridges run as in-process FastAPI endpoints, aggregated by api/mcp_registry.py. All bridges share the same backend process. If a bridge executes heavy or misbehaving tool logic (filesystem operations, browser automation, external process calls), it can affect the latency and stability of the entire backend.

Specific risks:

• A blocking call in one bridge stalls other requests on the same event loop
• An exception in a bridge that isn't caught cleanly can corrupt shared state
• No resource limits per tool category — one runaway tool can exhaust memory/CPU for all

Desired State

MCP bridges that execute external tools, run subprocesses, or perform I/O-heavy work should run in isolated processes (subprocess or container), communicating with the main backend over a defined transport (stdin/stdout MCP protocol, or lightweight HTTP).

Bridges with no side effects (pure computation, in-memory lookups) can remain in-process.

Isolation Candidates

Affected Files

• autobot-backend/api/mcp_registry.py
• autobot-backend/services/mcp_dispatch.py
• autobot-backend/api/filesystem_mcp.py
• autobot-backend/api/browser_mcp.py
• autobot-backend/api/vnc_mcp.py
• autobot-backend/skills/sync/mcp_transport.py

Acceptance Criteria

• High-risk bridges execute in isolated process or container
• Backend stability unaffected by a misbehaving bridge
• MCP registry and dispatcher unchanged from the caller's perspective
• Resource limits (CPU/memory) configurable per bridge category