[feature] distill_records 只有写入路径：给「这条记忆是哪次蒸馏带进来的」一个读出口 #421

要解决的问题

PR #417 按 #399 的约定把蒸馏窗口的原始记录落进了 distill_records，并把 memory → (session_id, seq_start, seq_end) 的归因写进 memory_provenance。但那次只做了写：没有任何读路径 —— 面板不显示、API 没有端点、service 没有查询方法。结果是这批数据只进不出：它占了库、进了回收面，却没人能看见。

具体场景：一条记忆的来源可疑（内容与原文对不上，或需要确认它到底是从哪几句里蒸出来的），现在唯一的办法是直接开 sqlite 手写 JOIN。而 #399 里「我们测不出自己丢了多少」这个目标，恰恰要靠读出口才成立。

期望的方案

给一个最小读出口，两个方向：

1. 按记忆看窗口：给定 memory_id，返回它在 memory_provenance 里的区间 [(session_id, seq_start, seq_end)]，再按区间取出 distill_records 的原文行。
2. 按会话看窗口：给定 session_id，列出该会话所有已留存的窗口（按 seq 升序）。

形态上倾向先走 GET /api/dsh-mneme/memory/provenance?memoryId=（面板与外部 API 同一份实现）；面板侧挂在哪里由维护者定。distillRecords.enabled=false 时按既有习惯返回空或 404，依附既有开关，不新增。上面两条是形态建议，不是实现要求。

考虑过的替代方案

• 直接暴露 distill_records 全表（连 text 一起）：数据面积与敏感度最大，且没有解决「从记忆回去」这个真实入口，先不做。
• 面板只显示条数、不返回原文：判断不了「原文里到底有没有这句话」，等于没解决 [feature] 蒸馏窗口原始记录留存 + 记忆级溯源：把蒸馏从「替换」降级为「叠加索引」 #399 的原始目标。

实现口径确认 / Implementation gates

• 新行为开关 opt-in 默认关（本提案依附既有 distillRecords.enabled，不新增开关）
• 无 schema 变更（只读既有两张表，无需迁移）
• 接受带回归测试的验收线

披露 / Disclosure

• 本提案由 AI 辅助整理（人工审核后提交）