feat(store): set busy_timeout on sqlite connections to avoid SQLITE_BUSY race

[fxstein]

What

Sets PRAGMA busy_timeout = 10000 (10s) on every SQLite connection qmd opens, at the single openDatabase() choke point in src/db.ts.

Why

When two processes share the same qmd store — e.g. a long-running MCP daemon and a qmd CLI invocation (often driven from a short-interval cron) — the second writer hits SQLITE_BUSY immediately and aborts, because SQLite's default is to error rather than wait on a locked database:

SQLiteError: database is locked
  code: "SQLITE_BUSY"
  at clearCache (.../store.js) ... at updateCollections (.../cli/qmd.js)

busy_timeout makes SQLite wait-and-retry for up to the timeout before giving up — the standard pattern for short-lived multi-process contention. 10s comfortably covers the typical write window of either side.

Details

• One-line change in openDatabase(), the only place qmd creates a connection (verified — the sole other open site routes through it). Applies uniformly under both bun:sqlite and better-sqlite3.
• No behaviour change for single-process use.
• tsc --noEmit clean.

[fxstein]

Closing as superseded by upstream. Since this PR was opened, main gained a more complete busy_timeout implementation in src/db.ts openDatabase():

• default raised to 120s (vs the 10s hard-coded here),
• made configurable via the QMD_SQLITE_BUSY_TIMEOUT env var (commit 616850d1),
• paired with enableWal() and a concurrent-open safety fix (5496df39, plus fix(db): guard SQLite store init against concurrent opens #686).

That covers the SQLITE_BUSY race this PR was targeting and then some, so there's nothing left for this change to add. Thanks!