bug: mcp_config.json file-watcher hot-reload doesn't propagate env (and likely headers) changes to running upstreams

[Dumbris]

Bug

The mcp_config.json file-watcher hot-reload does NOT propagate env changes to a running upstream server's docker container. Only a live REST PATCH (or equivalent CLI mcpproxy upstream patch) reaches the in-memory copy that the docker arg builder consumes.

Reproduction

Verified today on the macOS tray's bundled v0.30.1 daemon, but the code path is shared with the standalone binary.

1. Have a docker-isolated stdio server with env: {"FOO":"bar"} in ~/.mcpproxy/mcp_config.json.
2. Stop the daemon (or restart the server from the tray to confirm the container has env).
3. Edit the file: delete the env key from that server. Save.
4. Trigger restart (tray menu or mcpproxy upstream restart <name>). Container relaunches without the env — expected.
5. Edit the file again: put env back. Save.
6. Restart the server: container relaunches but STILL WITHOUT the env. The file change was not picked up.
7. Now run mcpproxy upstream patch <name> --env FOO=bar (live REST PATCH). Container relaunches with the env.

Step 7 confirms the wiring works — the watcher just isn't pushing the env-delta into the live config.

Real-world impact

Hit this during PR #466 verification. After accidentally wiping OBSIDIAN_VAULT_PATH from obsidian-pilot and restoring it via direct file edit, the obsidian server kept failing with:

ValueError: OBSIDIAN_VAULT_PATH environment variable must be set

…across multiple restart cycles — until we used mcpproxy upstream patch (the new subcommand from #466).

Where to investigate (pointers, not a fix)

• internal/upstream/core/isolation.go:464-466 — BuildDockerArgs() iterates serverConfig.Env; this works at startup.
• Whatever applies file-watcher reload to the running supervisor likely calls a server-update path that drops env (or headers?), or the watcher doesn't trigger a full server-config diff that includes those maps.
• Suspect the same gap exists for headers since they share the same edit surface.

Workaround

Use mcpproxy upstream patch <name> --env KEY=VALUE (added in PR #466) instead of editing the config file when you need env changes to take effect on a running server.