Unwrappable servers need to be identified and handled #2
Description
Most simple (npx/uvx) MCP servers are self-contained with respect to the host machine, requiring access to args and env vars, maybe mapped volumes, and access to the internet.
But some of these servers do their work by executing commands on the host machine, for example the "official" git server (which just execs the git command and parses its output). When we wrap such a server in our runner container, it will fail (because the container will not have access to the git command). Such servers are insecure by their nature and not wrappable in a generic container. They would require proper, bespoke containers to work (and for some such servers, even that might not be sufficient depending on what commands they execute and what dependencies on the host machine those commands have).
If you try to have ToolVault wrap ("run in container") one of these servers, it will succeed, but the servers will fail on requests. The log (available in ToolVault) will indicate the reason. You can just unwrap them and they work fine (still as a managed server, but no longer running in container, and of questionable security). This will cause a compliance warning in ToolVault (which is appropriate).
We should probably keep an exclude list of such servers so we don't auto-wrap them on import, we don't present the wrap option in the server config UX, and we probably have a warning in the server details that the server is unwrappable (and scary).