feat: container self-restart after mcp_add_tool / mcp_remove_tool

[kordless]

Problem

When an agent calls `mcp_add_tool` (or `mcp_remove_tool` / `mcp_set_tools`), the config is updated but the tool is not yet active — the container must restart. Currently the response includes a `next_step` hint but the agent treats it as informational rather than a required action. The agent then gets confused when the tool still isn't available.

Proposed solution

Add an optional `mcp_restart_container` tool that:

1. Writes a restart-marker file (e.g. `/workspace/.nemesis8-restarted`) with a timestamp before exiting — this file persists across restarts because it lives in the workspace volume
2. Calls `sys.exit(0)` (or sends `SIGTERM` to PID 1) to trigger container exit
3. nemesis8 (or the container entrypoint) detects the non-zero / SIGTERM exit and restarts the container as it normally would
4. On the next startup, the tool-manager checks for the marker file and returns a `restarted: true` field in `mcp_list_installed` / `mcp_show_config` so the agent knows it's in a fresh session after a tool change

Why the marker file approach

The agent has no memory across container restarts. The marker file is the only side-channel that survives. The tool-manager reads it at first call and deletes it so it only fires once per restart.

Acceptance criteria

• `mcp_restart_container` tool appears in the tool list
• Calling it writes the marker and exits the container
• On the next startup, `mcp_list_installed` returns `{ "restarted_for_tool_change": true }` once, then never again (marker deleted)
• Calling `mcp_restart_container` from an agent prompts the agent to tell the user: "Restarting container to apply tool changes."

Related

• Short-term workaround: strengthen the restart warning text in mcp_add_tool / mcp_remove_tool responses (separate commit)