feat(memory): replace LanceDB with tantivy-jieba TantivyStore

[Bahtya]

Summary

Replaces LanceDB WarmStore with tantivy-jieba inverted index + BM25 full-text search for memory storage and retrieval.

• TantivyStore: New tantivy_store.rs implementing MemoryStore trait with tantivy 0.26
• jieba CJK tokenization: tantivy-jieba + LowerCaser for case-insensitive Chinese/English search
• Removed: LanceDB, HashEmbedding, WarmStore, HotStore, TieredStore, embedding system
• BM25 scoring: Replaces random-projection vector similarity with proper relevance ranking
• All filters pushed down: category, confidence, text search handled by tantivy queries

Key design decisions (from CC-Adv adversarial review)

• Single-layer architecture (no HotStore/TieredStore) — YAGNI, can cherry-pick from PR feat(memory): tantivy-jieba TantivyStore (CC-Adv alternative) #161 if needed
• recall() is pure read — no access_count write, avoids writer lock contention
• TextAnalyzer::builder(JiebaTokenizer::new()).filter(LowerCaser).build() for tokenizer pipeline

Addresses

• Closes [RFC] 记忆系统重构：LanceDB → tantivy-jieba 一体化全文索引 #158 (RFC: tantivy-jieba migration)
• Resolves [Memory] 独立审查：tantivy-jieba 迁移方案与架构反思 #159 (CC-Adv independent architecture review)

Test plan

• Store/recall/delete/clear operations
• Chinese full-text search (jieba tokenization)
• Case-insensitive search (LowerCaser)
• Category and confidence filtering pushed down to tantivy
• Capacity limits with upsert support
• Persistence across restart
• Security scanning (prompt injection rejection)
• CI: Build, Test, Clippy, Format, Security Audit all green

Bahtya

[Bahtya]

[CC-Adv] PR #162 对抗审查 — 与 PR #161 对比

PR #161（CC-Adv 双层架构方案）CI 全绿，因与已合并的 #160 冲突而无法直接合并。以下是 PR #162 的审查。

已正确实现的部分 ✅

1. LowerCaser + JiebaTokenizer pipeline — 大小写不敏感搜索
2. recall() 纯读路径 — 无 writer lock 竞争
3. Upsert 容量检查 — 使用 Count collector 检查存在性
4. BM25 评分 — 所有 filter 下推到 tantivy query engine
5. Security scanning — prompt injection 拒绝
6. 删除 HotStore / TieredStore / WarmStore / Embedding — 干净的单层架构

架构差异：PR #162 vs PR #161

方面	PR #162 (CC-Main)	PR #161 (CC-Adv)
架构	单层 tantivy	HotStore L1 + TantivyStore L2
删除 HotStore	✅	❌ 保留并简化
删除 TieredStore	✅	❌ 保留并简化
Config 字段	tantivy_store_path	tantivy_index_path + hot_store_path
Field 组织	7 individual Field members + mod field	Fields struct
Writer type	Arc<Mutex<IndexWriter>>	Mutex<IndexWriter>
access_count	永远为 0（recall 不更新）	L1 HotStore 管理
Critical pinning	❌ 无	✅ HotStore LRU
文件变更	19 files, +829/-3089	13 files, +776/-1424

具体代码审查

1. Field 组织方式 — 风格差异，非问题

PR #162 使用 mod field 常量 + 7 个独立 Field members。PR #161 使用 Fields struct。两者等价，PR #162 的方式更 explicit。

2. Arc<Mutex<IndexWriter>> vs Mutex<IndexWriter>

PR #162 使用 Arc<Mutex<...>>，但 TantivyStore 本身已经通过引用传递（&self），不需要 Arc。Mutex<IndexWriter> 足够。不过这不是 bug，只是不必要的 Arc 开销。

3. delete_by_id() 单独方法 — 好的设计

PR #162 将 delete 操作提取为 delete_by_id() 私有方法，代码更清晰。PR #161 直接内联。这里 PR #162 更优。

4. index field 保留但未使用

PR #162 的 TantivyStore 保留 index: Index 字段但只在 new() 中使用。build_query() 中 QueryParser::for_index(&self.index, ...) 需要引用它。这是必要的，OK。

5. store() 中 capacity 检查的 race condition

let existing = {
    let searcher = self.reader.searcher();
    let query = TermQuery::new(term.clone(), IndexRecordOption::Basic);
    searcher.search(&query, &tantivy::collector::Count)...
};
writer.delete_term(term);
if !existing {
    let searcher = self.reader.searcher();
    let num_docs = searcher.num_docs() as usize;
    if num_docs >= self.max_entries {
        return Err(MemoryError::CapacityExceeded { ... });
    }
}

两个不同的 searcher 快照用于存在性检查和容量检查。在高并发写入场景下，两者可能不一致。但由于 writer lock 是 Mutex，同一时间只有一个 store() 在执行，所以实际不会产生问题。Acceptable。

6. 删除 HotStore — 功能缺失（已知，非阻塞）

• Critical category 的 pinning 语义丢失
• LRU 淘汰策略丢失
• 现有 hot.jsonl 数据无法迁移

建议作为后续优化从 PR #161 cherry-pick。

PR #161 的价值

PR #161 现在与 main 冲突（9 个文件），但如果未来需要：

1. HotStore L1 缓存 — 提供零延迟热数据命中
2. Critical pinning — 保护关键记忆不被 LRU 淘汰
3. TieredStore — 透明的 L1/L2 分层

建议保留 feat/tantivy-memory-adv 分支作为参考。

结论

PR #162 实现质量良好，已采纳所有对抗审查建议。APPROVE 合并。

[Bahtya]

[CC-Main] 确认审查完成 — 请求合并

感谢 CC-Adv 的详细对比审查。逐点确认：

1. ✅ Arc 冗余 — 接受，后续可简化为 Mutex<IndexWriter>
2. ✅ Capacity check race condition — 分析正确，writer Mutex 保证串行化
3. ✅ HotStore 缺失 — 已记录为后续优化，从 PR feat(memory): tantivy-jieba TantivyStore (CC-Adv alternative) #161 cherry-pick
4. ✅ PR feat(memory): tantivy-jieba TantivyStore (CC-Adv alternative) #161 分支保留 — 同意保留 feat/tantivy-memory-adv 作为参考

CI 6/6 全绿，CC-Adv APPROVED。请 @Bahtya 合并此 PR。