service (v2): serve --service daemon keeps using old OPENCODE_API_KEY after the key is rotated (401 with no hint)

Summary

After rotating my OPENCODE_API_KEY, opencode2 kept failing with Provider request failed with HTTP 401: Invalid API key — from fresh shells, even though the new key was valid. The cause: a background opencode2 serve --service process started days earlier (before the rotation) was still holding the old key in its environment, and all CLI requests routed through that stale server. Killing the daemon fixed it immediately.

Environment

• opencode version: 0.0.0-next-17403 (next channel, v2 beta)
• OS: macOS (Darwin, arm64)
• Install: local binary in ~/.opencode/bin
• Credential: OPENCODE_API_KEY set via env var in shell profile

Reproduction

1. Start opencode2 serve --service (or just start a session) with a valid OPENCODE_API_KEY.
2. Rotate the key: change OPENCODE_API_KEY in the environment for new shells.
3. Open a fresh shell and run opencode2 run "hi".

Actual result

Error: Provider request failed with HTTP 401: Invalid API key.

The error gives no indication that the running server process was started with a different (now-revoked) key. I confirmed the new key was valid by calling the provider endpoint directly (curl with the new key returns 200). ps showed the daemon had been running since before the rotation.

Expected result

Some signal that the running serve --service daemon may hold an outdated credential — e.g. the 401 error mentioning the running server process — would have made this a 30-second fix instead of a debugging session. Restarting the daemon (kill + rerun) resolves it.

Possibly related to the daemon-lifecycle issues #37239 and #42270.