MCP subprocess respawn brittleness after backing package upgrade

Context

I've been building khimaira-chat, a multi-agent orchestration MCP server for Claude Code. It ships as a Python package on PyPI; the MCP integration runs the server as a stdio subprocess spawned by Claude Code.

Symptom

When the user upgrades the backing Python package mid-session (pip install --upgrade khimaira-chat), the running stdio subprocess keeps the OLD code loaded in memory. The agent-facing behavior then becomes a mix of "old subprocess running old code" plus "new code on disk that isn't being executed."

Specifically:

1. Tools added in the upgrade don't appear in the agent's tool list
2. Bug fixes in the upgrade don't apply
3. notifications/tools/list_changed from the old subprocess can only re-announce the OLD list — it can't recover the case where the subprocess itself is running stale code (see related: #59501)
4. The only fix is to close+reopen the Claude Code window

Workaround we shipped

A daemon-side watchdog that re-registers the MCP subprocess every 30s via claude mcp (commit fb02ac6). This helps when registration is the problem; it doesn't help when the subprocess itself is the problem (Python module cache holds old imports).

What would help

Any of:

1. A way to gracefully respawn an MCP subprocess from inside Claude Code (e.g., /mcp restart <name>)
2. Claude Code detecting backing-package version mismatch between disk and running subprocess, prompting the user to restart
3. Documentation clarifying that backing-package upgrades require subprocess restart and that tools/list_changed is not a recovery primitive for this case

Happy to provide

More detail on specific repro paths if useful. We hit this pattern multiple times across our v1.0 → v1.5 iterations before establishing the "restart Claude Code after every package upgrade" hygiene.