MCP-based LocalDockerClient sketch

[mx781]

This is a POC of what the HUD system would look like if we were to use an MCP server as the env controller interface as opposed to pure docker execs with predefined functions.

The pros:

• Familiar to the end user; easy to integrate if they have an existing MCP server
• Controller can be implemented in any language (MCP has SDKs in quite a few) for customizability while preserving the existing python devX including hot reloading
• Easy to have the controller be stateful - previously state would have to be serialized to disk (or kept in a wholly different process)
• Paves way to removing execute from our interface which is probably desirable so users need not have full-fledged access to env (e.g. if a customer has supplied this for them)

The cons:

• It's far more complicated than the previous setup. There is now a controller manager, a background thread for the log streaming, startup/teardown scripts, etc. All of this means possibly more sharp edges. It's definitely not production ready as of this PR.

Other improvements from previous state:

• Only (exotic) dependency is uv - no need for base dockerfile to have Python
• Use of venv for controller reqs to keep things isolated and avoid potential pains from --break-system-packages

Todo:

• The startup is a bit slower now. For one, this could be improved by a more sophisticated signaling mechanism for MCP server readiness.
  • But more importantly, we should relay progress to the user. Currently simply setting loglevel to INFO is a bit too verbose and not great UX.
  • Log streaming should also be toggle-able probably.
• RemoteDockerClient: not done as part of this PR to trial out locally first. The controller log streaming might be a bit annoying if we keep it since we need to spin up a WS server to pass through to the K8S exec WS stream.
• (for debate) I simplified the setup to a requirements.txt in favor of pyproject.toml @pimpale suggested this makes for a poorer devx in e.g. cursor since the server.py no longer knows its part of a different project than whatever parent is. This can definitely be reverted, but requirements.txt felt like the minimal-needed thing which is why I picked it here.
• Support for self-managed controllers (basically, don't touch container once spun up, don't hot-reload). We need to decide where the flag to toggle this would live.
• Tests: basically didn't have leftover time for this.

[promptless]

📝 Documentation updates detected! You can review documentation updates here