update starts its own daemon when systemd already manages it

I run msgvault serve as a systemd service (Restart=always, RestartSec=10). When I run msgvault update (v0.21.0 → v0.22.0, Linux):

1. The updater asks the running daemon to shut down. It exits cleanly.
2. The updater starts a new msgvault serve in the background. Its parent is pid 1, so systemd does not know about it.
3. Ten seconds later, systemd restarts its own copy. That copy fails with bind: address already in use on the API port, and systemd retries every 10 seconds without end.

The API keeps working, because the updater's copy serves it. But systemd no longer manages the daemon, so a crash or a reboot is not handled the right way. Stopping the updater's copy by hand fixed it: systemd's next restart then succeeded.

This is not the #940 panic. That one is fixed: the restart now succeeds. The problem is that the restart happens at all when a service manager owns the daemon.

Suggestion: if the daemon runs under systemd (or launchd), update should replace the binary and not restart the daemon. It could print "restart it with systemctl restart msgvault". One way to detect systemd: the running daemon's cgroup in /proc/<pid>/cgroup ends in .service, or INVOCATION_ID is set in its environment. A --no-restart flag would also help.

Workaround: stop the service before update, then start it again.