Delete summary lineage, context items, and FTS rows ahead of conversation deletion so prune works against the current schema's RESTRICT edges. Add a regression test that prunes a conversation containing summary_messages and context_items.

Regeneration-Prompt: |
  Running the prune helper against the live LCM database exposed a schema-level failure that the existing tests missed. Deleting a conversation directly did not work because several child tables mix CASCADE links from conversations with RESTRICT links back to messages and summaries. Reproduce that case with a test conversation that has a message, a linked summary, summary_messages lineage, and a context_items row. Then change prune so confirm-mode deletes the dependent rows in a safe order before deleting the conversation, and also clear any optional FTS rows tied to the pruned messages and summaries so search indexes do not retain orphaned entries.

Chunk confirmed pruning into bounded transactions so large live databases can be cleaned incrementally without one giant write lock. Delete cross-conversation context rows that reference pruned summaries or messages, and add supporting indexes plus regression coverage for batch mode and retained-context cleanup.

Regeneration-Prompt: |
  The prune helper already handled mixed timestamp formats and dependent summary/message cleanup, but it still did not work reliably on a large live LCM database. Update it so confirm-mode pruning runs in small committed batches instead of one giant transaction. Add options to control batch size and an optional max batch count for bounded runs. Preserve dry-run behavior.

  While testing against a large live database, pruning exposed an additional FK case: retained conversations can keep context_items rows that reference summaries being pruned from another conversation. Extend the delete path to remove context_items rows by referenced candidate message_id and summary_id, not just by candidate conversation_id. Keep the existing summary_messages and summary_parents cleanup.

  Add regression tests for multi-batch pruning, bounded batch runs, and the cross-conversation context_items case. Also add the missing indexes needed for live-scale deletes on summary_messages(message_id) and summary_parents(parent_summary_id).

Follow VACUUM with wal_checkpoint(TRUNCATE) so operator-triggered prune runs reclaim disk space immediately in WAL mode instead of leaving the rewritten pages stranded in lcm.db-wal. Add a regression test that verifies the WAL is drained after a vacuumed prune.

Regeneration-Prompt: |
  The prune helper already supports an optional vacuum pass after confirmed deletion, but in WAL mode that still leaves reclaimed pages sitting in the WAL file until a checkpoint happens. Update the vacuum path so a prune with vacuum enabled also runs PRAGMA wal_checkpoint(TRUNCATE) immediately afterward. Keep the existing API shape.

  Add a focused regression test in prune.test.ts that proves the WAL is drained after a vacuumed prune, for example by checking PRAGMA wal_checkpoint(PASSIVE) returns zero log frames after the prune completes.