fix(supervise): provision MCP via claude mcp add, not raw settings.json

The previous provisioner wrote ~/.claude/settings.json with an
mcpServers entry — but claude-code doesn't read its mcpServers from
that path. Inside a bottle, /mcp showed "No MCP servers configured"
even though the sidecar was running.

Switch to the official `claude mcp add` command run via docker exec:

  docker exec -u node <agent> \
    claude mcp add --scope user --transport http supervise <url>

claude-code owns its config file format (~/.claude.json shape, key
names, scope semantics) and has changed it between versions. The
official command writes to the right place in the right shape for
whatever version is installed.

Failure is logged but not fatal — the bottle still works; you just
have to register the server manually with the command surfaced in
the warning. Worst case is a bad agent claude-code version, not a
bad bottle.

To fix an already-running bottle without restarting, the user can
run the same `docker exec` command directly.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

tests/unit/test_provision_supervise.py

@@ -1,37 +1,29 @@
-"""Unit: supervise MCP settings renderer (PRD 0013 follow-up).
+"""Unit: supervise MCP provisioning (PRD 0013 follow-up).
 
-The docker cp / chown side of provision_supervise is exercised by
-the existing supervise integration test once the agent container is
-brought up; here we cover the pure render path so a settings.json
-shape regression would surface in unit-level CI."""
+The real provisioning runs `claude mcp add` inside the agent
+container — exercised by the existing supervise integration test
+chain once the agent container is brought up. Here we just cover
+the URL computation so a regression in SUPERVISE_HOSTNAME / PORT
+plumbing surfaces in unit CI."""
 
-import json
 import unittest
 
-from claude_bottle.backend.docker.provision.supervise import render_settings
+from claude_bottle.backend.docker.provision.supervise import supervise_mcp_url
 from claude_bottle.supervise import SUPERVISE_HOSTNAME, SUPERVISE_PORT
 
 
-class TestRenderSettings(unittest.TestCase):
-    def test_output_is_valid_json(self):
-        json.loads(render_settings())
-
-    def test_has_mcp_servers_supervise_http_entry(self):
-        cfg = json.loads(render_settings())
-        servers = cfg["mcpServers"]
-        self.assertIn("supervise", servers)
-        sv = servers["supervise"]
-        self.assertEqual("http", sv["type"])
+class TestSuperviseMcpUrl(unittest.TestCase):
+    def test_url_matches_sidecar_constants(self):
         self.assertEqual(
             f"http://{SUPERVISE_HOSTNAME}:{SUPERVISE_PORT}/",
-            sv["url"],
+            supervise_mcp_url(),
         )
 
-    def test_only_supervise_server_is_emitted(self):
-        cfg = json.loads(render_settings())
-        # Keep the provisioner narrowly scoped — it owns just the
-        # supervise entry, no other tools/servers.
-        self.assertEqual({"supervise"}, set(cfg["mcpServers"].keys()))
+    def test_url_is_http_not_https(self):
+        # The agent dials the sidecar on the internal docker network;
+        # no TLS termination, no CA trust juggling. If this ever
+        # needs HTTPS, the sidecar's listener side has to change too.
+        self.assertTrue(supervise_mcp_url().startswith("http://"))
 
 
 if __name__ == "__main__":