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