fix(store): checkpoint WAL on close and startup to prevent orphan accumulation

[jjserenity]

Fixes #277

Problem

codebase-memory-mcp processes can accumulate as orphan processes (e.g., from unclean stdio shutdown on Windows). Each orphan holds a SQLite WAL read lock, preventing checkpoint from ever landing. New index writes go to WAL but never merge into the main .db. The WAL grows unbounded, and queries return stale data.

The existing cbm_store_checkpoint() API uses safe SQLITE_CHECKPOINT_PASSIVE mode but is never called anywhere — zero call sites.

Changes

Single file: src/store/store.c (+10 lines)

1. cbm_store_close(): Checkpoint WAL via sqlite3_wal_checkpoint_v2(..., PASSIVE) before sqlite3_close_v2. This ensures graceful shutdown (SIGTERM, delete_project, normal exit) leaves a clean WAL that won't require recovery on next open.

2. configure_pragmas(): After PRAGMA journal_mode=WAL, run PRAGMA wal_checkpoint(PASSIVE) to merge any stale WAL from a previous crash. Best-effort — silently skipped if another process holds a lock (SQLITE_BUSY).

Rationale

• PASSIVE mode never blocks readers and never ftruncate()s, compatible with PR fix(store): use PASSIVE checkpoint to avoid file-shrink under concurrent readers #316's existing choice.
• Crash + restart → startup checkpoint recovers the WAL.
• Graceful exit → WAL is clean.
• delete_project → checkpoint runs inside cbm_store_close before file unlink, so WAL is merged before deletion.
• Orphan processes still holding locks → checkpoint silently fails, no regression.

Tested

• Compiles clean on MinGW GCC 14.2 (-Wall -Wextra -Werror)
• CI will verify full test suite

[DeusData]

Thank you, @jjserenity! 🙏 This is a sharp, minimal fix for a genuinely nasty failure mode. You correctly identified that the existing cbm_store_checkpoint() had zero call sites, so WAL was never being merged — and that orphan processes holding a WAL read lock would let it grow unbounded while queries returned stale data (#277). Checkpointing on close and recovering a stale WAL at startup, both in PASSIVE mode (never blocks readers, never ftruncates — consistent with the project's existing checkpoint guidance), is exactly right. I also like that the close-path guard skips in-memory DBs (no db_path → no WAL).

Verified locally: build clean, all 3,622 tests pass. Merging via squash — authorship preserved. Closes #277, and this is a big one for the silent-corruption cluster tracked in #391. Thank you! 🙏