fix(db): guard SQLite store init against concurrent opens

[brettdavies]

Fixes three crashes that hit when multiple qmd processes open the same index at once: the failure mode in #710 (an update or query racing a long embed, an agent fanning out searches, or a first-open migration racing a routine command).

Root cause

Three independent faults on the shared createStore → initializeDatabase path, all triggered by concurrent opens:

1. SQLITE_BUSY: database is locked on any contended write. bun:sqlite and better-sqlite3 both default busy_timeout to 0, so a writer that loses the lock throws on contact instead of waiting. WAL lets readers and one writer coexist but does not serialise writers.
2. trigger documents_ai already exists. The FTS sync triggers were dropped and recreated on every open as separate autocommit statements, so two connections interleave between the DROP and the CREATE (A drops, B drops, A creates, B creates, throw). busy_timeout serialises individual statements but not the DROP/CREATE pair.
3. database is locked while migrating a cold database to WAL. PRAGMA journal_mode = WAL needs a brief exclusive lock and does not invoke the busy handler, so concurrent first-ever opens throw immediately regardless of busy_timeout.

Fix

• src/db.ts: openDatabase sets PRAGMA busy_timeout (default 120000, override QMD_SQLITE_BUSY_TIMEOUT; 0 restores fail-fast) and enables WAL with a bounded retry within the same budget, so the cold-database journal migration survives concurrent opens. Connection-level pragmas now live in one place.
• src/store.ts: the FTS trigger rebuild is gated behind PRAGMA user_version and applied inside one IMMEDIATE transaction with a double-checked read. The DROP/CREATE pair is atomic across connections and runs once per schema version instead of on every open. Bump STORE_SCHEMA_VERSION to reissue changed trigger bodies to existing databases.

Tests

• test/db.test.ts: busy_timeout default, per-connection application, env override, =0 fail-fast, garbage-falls-back-to-default, and a real-lock-contention timing check.
• test/store-concurrency.test.ts (new): spawns N processes that open the same database at once (cold and existing), asserting no already exists / database is locked throw and that the triggers, FTS table, and user_version survive. Fails against the pre-fix code, passes after.
• tsc -p tsconfig.build.json --noEmit clean. Node and Bun suites pass; the LLM-pipeline integration tests fail in this environment on VRAM pressure (same baseline noted in feat(serve): qmd serve shared model server + RemoteQMD client (supersedes #511) #663) and reproduce identically against bare main.

Closes #710.