Add single-instance service management and strict production port handling

[mydmdm]

Summary

Add a supported way to run Huabu as one supervised local service, stop the complete Huabu process tree, and prevent production-style startup from silently selecting another port when an older instance is still running.

Motivation

pnpm start:web currently calls findAvailablePort(). If an old Huabu instance still owns port 3001, a newly built instance starts on 3002. Existing browser sessions and Agent RFS environments can remain attached to the stale port-3001 instance, making the update appear ineffective and allowing multiple Server/Agentlet process trees to coexist.

Managing the process manually in tmux makes it easy to leave an old Server or Agentlet alive.

Proposed scope

• Provide a documented and supported systemd user service for local Linux deployments.
• Run the Server and all child processes in one service cgroup.
• Stop the complete process tree with KillMode=control-group.
• Use Restart=on-failure and expose status/log commands.
• Add a strict production port mode: when the configured port is occupied, fail with a clear error instead of falling forward to another port.
• Keep automatic next-port selection available for development workflows where multiple instances are intentional.
• Add a single-instance guard keyed by the effective HUABU_DATA_DIR, so two processes cannot concurrently serve the same data directory.
• Provide a safe update workflow: stop, pull, install, build, start, and verify readiness on the configured port.
• Document one-time migration from unmanaged tmux processes using port inspection and exact-PID termination; do not recommend broad pkill/killall commands.

Acceptance criteria

• Starting a second production Huabu instance for the same data directory is rejected deterministically.
• A configured production port conflict fails instead of selecting a different port.
• Stopping the service terminates its Server, Agentlet, and other child processes.
• Start, stop, restart, status, logs, enable/disable, and full-cgroup kill commands are documented.
• The update workflow verifies that exactly the intended port is listening and that readiness succeeds.
• Development startup retains an explicitly documented multi-instance/port-fallback behavior.
• Tests cover strict-port conflict handling and the single-instance guard where practical.

Context

This was observed while investigating #166: an instance started before #161 remained on port 3001, while a rebuilt instance automatically started on port 3002. The active Space and Agent Thread remained connected to the stale port-3001 instance.