Concurrent runs can fail on shared snapshot gc.pid.lock

Bug

OpenCode 1.18.30 can fail a concurrent opencode run because snapshot cleanup races on the shared global Git snapshot repository.

Observed on macOS during a real long-running soak with one project and multiple concurrent opencode run --auto processes:

cleanup failed exitCode=128
fatal: Unable to create `/Users/abu/.local/share/opencode/snapshot/global/<snapshot>/gc.pid.lock`: File exists.
Another git process seems to be running in repository, or lock file may be stale

The Memory V1 backend remained healthy during the same run: 17 real sessions, 790 native sources, 302 tool starts, 0 failed memory jobs, 0 pending jobs. One OpenCode process exited non-zero due to the snapshot lock contention.

Expected

Concurrent sessions should serialize snapshot GC, retry lock contention, or treat a competing cleanup as non-fatal without failing the user session.

Reproduction

1. Use one OpenCode project/worktree.
2. Start two or more opencode run --auto processes concurrently.
3. Let them perform normal read/tool work so snapshot tracking and cleanup run.
4. Observe cleanup failed and occasional non-zero session exit.

Tracking report in the affected integration: https://github.com/Abuarchiv/agent-memory-v1/issues/1