upgrade: long-running serve from previous version keeps running after auto-update (404 on /api/status, service exits)

Summary

After an auto-update (autoupdate: true, 2.0.5 → 2.0.7), the previously running background serve process is not stopped. The stale process keeps reconnecting to the new installation: /api/status returns 404, service registration data appears missing/overwritten, and the background service exits. Killing the stale process restores normal startup.

Environment

• opencode version: 2.0.7 (upgraded from 2.0.5)
• OS: macOS (Darwin 27.0.0, arm64)
• Terminal: Ghostty, TERM=xterm-256color
• Shell: /bin/zsh
• Install/channel: latest (npm @opencode/cli), autoupdate: true
• Active plugins: /Users/zhangxiaokang/Workspace/opencode2-quota

Reproduction

1. Start opencode's background service (e.g. opencode serve) and leave it running.
2. Keep that process alive, then install / auto-update to a newer version (here 2.0.5 → 2.0.7).
3. Observe the previous-version serve process continuing to run and reconnect to the updated on-disk state.
4. Use the service / open a session.

Expected Behavior

• An upgrade should terminate or cleanly hand off the long-running serve process from the previous version, or otherwise prevent a stale process from reconnecting against the new installation.
• The background service should stay healthy after the upgrade.

Actual Behavior

• The old process logs repeated reconnection attempts and /api/status returns 404.
• Service registration data appears lost / overwritten ("service registration file …", "background service exited").
• The background service exits and opencode appears broken until the stale process is killed manually.

Additional Context

• Frequency: occurred once, immediately after the upgrade, only while a stale previous-version serve process was still alive. Killing that process recovered startup instantly; not reproducible when only a single current-version process is running.
• Workaround: terminate all stale opencode processes before/after upgrading, or restart the service after the upgrade.
• Related but separate: this environment also overrides the data location via the OPENCODE_DB env var; that caused a different symptom (sessions appearing missing due to the wrong DB being opened by a non-interactive start), not the 404/registration failures described here.