opencode mcp debug leaves a lock behind on exit, delaying the next session by ~60s

Running opencode mcp debug "<remote-oauth-mcp>" against a remote OAuth MCP server that has stored tokens leaves a lock directory under ~/.local/state/opencode/locks/. It is not removed when the command exits, and while it remains, the next process that reads mcp-auth.json is delayed by about 60 seconds. This includes starting a new session against that server, which blocks for roughly 60 seconds while connecting.

Starting from an empty ~/.local/state/opencode/locks/ and a remote OAuth MCP server with valid stored tokens:

opencode mcp debug "<remote-oauth-mcp>"   # ~2s; succeeds, but leaves a <hash>.lock directory under locks/
# then start a session that uses that server (for example `opencode`, or an ACP client via `opencode acp`)
# the session blocks for ~60s while connecting, then continues

The command also affects itself when run consecutively:

opencode mcp debug "<remote-oauth-mcp>"   # first run: ~2s
opencode mcp debug "<remote-oauth-mcp>"   # second run: ~60s, blocks for the full duration, then proceeds

In each case a <hash>.lock directory is present after the first run that was not there beforehand. The next read waits until the lock is treated as stale (about 60 seconds) before proceeding; removing the directory in advance avoids the delay. The leftover appears to be the lock guarding mcp-auth.json (the locking added in #29852); it is not released when mcp debug exits, so a session that reads the same file afterwards waits on it.

Expected behaviour: once mcp debug exits, the lock is released and subsequent reads and connections are not delayed.

Environment:

• opencode 1.18.4
• reproduced on macOS, Linux and Windows (same ~/.local/state and ~/.local/share layout on each)
• remote OAuth MCP server with stored tokens in ~/.local/share/opencode/mcp-auth.json