fix(opencode): raise SQLite busy_timeout to 10s

[divitkashyap]

Issue for this PR

Closes #21215

Type of change

• Bug fix

What does this PR do?

Bumps PRAGMA busy_timeout on the main opencode.db connection from 5000ms to 10000ms.

The 5s value was added in #10597 and helped, but issue #21215 includes a fresh log line error=database is locked ... +5015ms showing the writer is still blowing past the 5s window on busy DBs (1.3GB file, 11 FDs from one TUI, parallel opencode run workers). Doubling the wait lets SQLite ride out the longer WAL holds instead of surfacing SQLITE_BUSY into the session processor, which currently halts the in-flight turn with no retry.

One-line change. Not a substitute for the per-session sharding work in #20935/#21579, just buys headroom in the meantime.

How did you verify your code works?

• bun turbo typecheck passes (run by the pre-push hook, 15/15 packages green)
• Matches SQLite's documented guidance for WAL-mode DBs with concurrent writers (bump busy_timeout so the OS-level retry loop covers contention windows)
• Did not write a new unit test: the existing packages/opencode/test/storage/ suite has no precedent for asserting runtime PRAGMA values on the live Client(), and a contention repro is a multi-process integration test outside the scope of this minimal change

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[divitkashyap]

@thdxr — this touches the same pragma block you added in #10597. Happy to adjust the value or drop this in favor of retry logic if you'd rather tackle the underlying lock-hold-duration issue raised in the latest #21215 comment (writes serializing for 5s+ during large bash-tool output). Just figured a one-line bump was worth shipping while the sharding PR (#21579) cooks.