Avoid SQLite startup races during parallel Bun qmd initialization

[sebkouba]

Problem

Parallel qmd processes can fail during startup with transient SQLite lock errors such as database is locked and SQLITE_BUSY_RECOVERY.

Root cause

• busy_timeout was applied after early startup work
• the sqlite-vec probe could run before contention handling was configured
• multiple processes could race while flipping the shared database into WAL mode

Fix

• configure connection pragmas before any sqlite-vec probe work
• skip redundant PRAGMA journal_mode = WAL when the database is already in WAL mode
• tolerate losing the WAL transition race instead of aborting startup
• add focused regression coverage for concurrent Bun startup on both fresh and existing databases
• run that regression through a tiny Bun startup harness so CI measures DB initialization directly instead of full CLI latency

Testing

• bun test --timeout 60000 --preload ./src/test-preload.ts test/cli.test.ts
• bunx vitest run --reporter=verbose test/store.helpers.unit.test.ts test/store.test.ts test/cli.test.ts
• manual repro on a fresh DB: two concurrent bun src/cli/qmd.ts vsearch test runs exit 0 with no lock-related stderr
• manual repro on an existing DB: same concurrent vsearch repro exits 0 with no lock-related stderr