跨类型同义双录（如 pitfall + constraint）在去重与 #641 分诊链路上的盲区 #687

今天在本地长期库（0.14.0，约 1650 条活跃记忆）上顺手跑了一次不限 type 的全量向量余弦比对，发现一个挺有意思的现象，跟 #641 刚好能对上：

目前同类型的近重复其实已经被 autoDream 和冲突链路清得很干净了，库里残存的高相似对几乎全是跨类型的：

• sim >= 0.90 共 7 对：同类型仅 1 对，跨类型 6 对（86%）
• sim >= 0.88 共 24 对：同类型仅 3 对，跨类型 21 对（88%）
• sim >= 0.85 共 81 对：同类型仅 9 对，跨类型 72 对（89%）

翻了一下具体条目，最典型的是同一次编码调试对话被蒸馏时，模型经常把同一件事拆成一条 pitfall（现象+根因+规避方法）外加一条 constraint（工程约束），有时后续还跟着一条 decision / project 或 sleep 提出来的 pattern（比如一条 [pitfall] 某工具发送文件必须在允许目录内 和一条 [constraint] 某工具发送本地文件路径限制，相似度 0.917）。

顺着代码看了一圈，这类跨类型双胞胎目前刚好卡在三处过滤的夹缝里：

1. 蒸馏源头（src/lang.js:18 codingSummary）：提示词鼓励拆成多条，同时给了概念边界有重叠的 pitfall（含解决/规避方法）和 constraint，没提示同一结论择一 type 记录，模型很自然会交两份。
2. 落库去重（src/service.js:1490 findSessionDuplicate）：store.list({ type: memory.type, source }) 锁了同 type + 同会话，且 summarize.js 同一批次内是先查完再去落盘，同窗双录互相看不见。
3. 巩固与 [Feature] 冲突处理第二机制（beta）：确定性分诊 + 矛盾账本 + 惰性消解（零人工） #641 分诊入口（src/dream/clustering.js:117 findPotentialConflicts）：第一行 if (memories[i].type !== memories[j].type) continue; 直接跳过了异类比对，所以这 88% 的跨类型高相似对进不了 conflict_pending 和 conflict_ledger，在观测账本里也完全隐身了。

想到的一个低风险思路（不碰 #339 dreamMergeGuard，也不放开容易坏事的跨类型 LLM merge）：

• 源头：codingSummary 补一句互斥约束（同一个坑既然在 pitfall 里写了规避方法，就不再重复单开一条同义 constraint），顺便在单次蒸馏批内做一下高相似去重；
• 存量消解：在 [Feature] 冲突处理第二机制（beta）：确定性分诊 + 矛盾账本 + 惰性消解（零人工） #641 的确定性分诊里，考虑对语义高度重合的近亲类型对（比如 pitfall ↔ constraint、decision ↔ project）放开进入 T1 dup，复用 supersedeInfoFirstPair / superseded_by（留信息更完整的一条，正文零改写）。

供参考，看看合不合适并进 #641 后续阶段一块考虑～