Concurrent VS Code instances still silently crash — busy_timeout=0 still present

This is a continuation of #21215 and #15188 which were auto-closed due to inactivity. The underlying issue is still present and actively affects VS Code users.

Symptom: Running two or more VS Code windows/workspaces on the same project causes one or more OpenCode instances to silently die mid-session. No error dialog, no crash report — the process just vanishes.

Root cause (confirmed in #21215 and #36775): All OpenCode instances share a single SQLite database at ~/.local/share/opencode/opencode.db with PRAGMA busy_timeout = 0. When multiple processes write concurrently, SQLITE_BUSY fires immediately instead of retrying, and the error is silently swallowed in the streaming pipeline.

Confirmed still present on v1.17.15:

$ sqlite3 ~/.local/share/opencode/opencode.db "PRAGMA busy_timeout"
0

Impact: The VS Code extension design inherently spawns one server process per window, so multi-window workflows hit this constantly. This also affects anyone running opencode run in CI with parallel workers, or running the TUI alongside the desktop app.

Request: The sst/opencode fork already ships busy_timeout = 5000 — a one-line, backward-compatible change. Could this be applied upstream as a stopgap while the per-session DB sharding (#20935) is evaluated?

Environment:

• OpenCode version: 1.17.15
• OS: macOS 26.2 (arm64)
• Using VS Code extension with multiple windows