[epic] SQLite persistent stores

[dgenio]

Overview

Consolidate all SQLite-based persistent store issues into a single trackable epic. The in-memory stores (InMemoryEventLog, InMemoryArtifactStore, InMemoryEpisodicStore, InMemoryFactStore) are fine for single-session agents, but multi-session and production deployments need durable persistence.

Motivation

• Agents that run across sessions lose all context (event history, facts, artifacts) when the process ends
• The protocol-based store design (protocols.py) was built for exactly this — backend extensibility without changing core pipeline code
• SQLite is the right first backend: zero-config, file-based, no server, works everywhere Python runs

Children (consolidated from existing issues)

• [store] SqliteFactStore — persistent key-value fact backend #124 — SqliteEventLog implementing EventLogProtocol
• [store] SqliteArtifactStore — persistent artifact storage backend #126 — SqliteArtifactStore implementing ArtifactStoreProtocol
• [store] SqliteEventLog — persistent event log backend #128 — SqliteEpisodicStore implementing EpisodicStoreProtocol
• [store] SqliteEpisodicStore — persistent episodic memory backend #129 — SqliteFactStore implementing FactStoreProtocol

Implementation Notes

• All stores go in src/contextweaver/store/ alongside existing in-memory implementations
• Must implement protocols from protocols.py — no protocol changes needed
• SQLite is an optional dependency (add sqlite extras group in pyproject.toml)
• Tests: one test_store_sqlite.py covering all 4 stores with the same interface contracts as in-memory tests
• Consider a shared _sqlite_base.py for connection management if there's meaningful reuse

Acceptance Criteria

• All 4 SQLite stores pass the same behavioral tests as their in-memory counterparts
• StoreBundle works with any mix of in-memory and SQLite stores
• make ci passes
• Migration/schema versioning documented for future schema changes