[quickbeard]

Summary

Found while testing #377. opencode.db runs in WAL mode, and @codev/upload's Bun session reader opened it read-only. A read-only connection can't create the -wal/-shm side files that a WAL read needs:

• While any CoDev process has the store open, the side files exist and the read works. That covers most launch-time pushes, which race a running TUI or server.
• After the last process closes cleanly the side files are deleted, and Bun's SQLite fails the first query with SQLITE_CANTOPEN. readAllSessions / readAllSessionStats then throw, the exporter logs "session store read failed", and the user sees "No sessions found". That hits codev upload, codev upload --logs and codev debug stats whenever nothing else is running.

Reproduced on a copy of a real 52-session store with the side files removed: before the fix SQLITE_CANTOPEN; after it, 52 sessions for both stats and log export.

Fix (packages/codev-upload/src/sqlite.bun.ts, fork-only, so no DIVERGENCES.md row):

• Open read-only as before and probe with a cheap schema read.
• Only on SQLITE_CANTOPEN, reopen with { readwrite: true, create: false } so SQLite recreates the side files the way any reader of a WAL database does. The reader still only runs SELECTs, and a missing store is never created.
• node:sqlite (the desktop sidecar's driver) already handles this case, verified under Node 24. Its code is unchanged, and the parity test now covers it.

Test plan

• bun test in packages/codev-upload (60 tests). New:
  • the Bun driver reads a checkpointed WAL store with no side files (fails without the fix);
  • the Bun driver never creates a missing store;
  • the Node parity test also runs against the WAL fixture under real Node.
• bun typecheck in packages/codev-upload
• A copy of a real session store in the failing state: SQLITE_CANTOPEN before, 52 sessions after

🤖 Generated with Claude Code