Checklist

• 我已经搜索过相关问题，但没有得到预期的帮助。
• 最新版本中该错误尚未修复。
• 已提供可追溯的会话、版本、审核日志与最小复现路径。

🐞 问题详细描述

在开启 ScienceMemory 和 Reviewer Specialist 的会话中，主 Lead 根据 REVISE_AND_RETRY 反馈修订同一 Markdown 报告后，第一份修订版保留了正文中的 [evidenceN] 标记，却没有保留/重新写入该 Artifact version 上对应的 Evidence reference（Memory 芯片）。

因此下一次 Reviewer 的 quick evidence check 将所有仍存在的标记判为 CITATION_EVIDENCE_ALIAS_UNRESOLVED，造成额外的无效修订循环；后续版本在重新声明 claim/evidence 后才恢复芯片。

最小复现路径：

1. 启用 ScienceMemory 与 Reviewer Specialist，生成带 [evidence1]... 标记和可点击 Evidence 芯片的 Markdown report。
2. 对该 report 执行 deep review，使其返回 REVISE_AND_RETRY。
3. 主 Lead 仅按审核意见修改同一 report 内容并 declare_artifact 生成新版本（未再次对所有未改动的引用执行 declare_claim）。
4. 对新版本执行 quick review。

实际结果：新版本中的 [evidenceN] 仍可见，但 version references 为空/缺少同名 evidence reference；quick review 对每个标记产生 CITATION_EVIDENCE_ALIAS_UNRESOLVED，推动 Lead 再次修订。

期望结果：若新版本保留同名 [evidenceN] 标记且没有新的同名映射，应从被修订 report 的上一版本继承仍被引用的、版本绑定的 Evidence reference（或在声明新版本时显式重建映射）。新旧内容中被删除的标记不可继承。这样首个修订版即可继续访问 Memory 芯片，并避免把“芯片丢失”误报为新的引用问题。

详细的环境信息描述

• 仓库：openJiuwen/sciencediscovery
• 本地工作区 HEAD：c1ab6327 Fix reviewer evidence presentation
• Reviewer Specialist model：GLM-5.2
• Session：4fadcc80-cce1-4309-bbf1-6cae7938c2d2
• Artifact：TP53_breast_cancer_report.md，artifact id f0c32d91-735e-4e8d-933c-83fb26297aad
• ScienceMemory：Neo4j healthy（同一 Session 的 memory graph 日志持续返回 subgraph）
• 发生时间：2026-09-16（日志时间为 UTC；界面版本列表为 Asia/Shanghai）

其他辅助信息

定位证据：

1. v2（artifact version id 0f3bc14e-0ffc-4346-b1f0-da1008bfa79f）的 deep review 于 2026-09-16T06:50:18.027Z 持久化为 REVISE_AND_RETRY，原因为 computation findings，不是引用芯片问题。
2. 随后的 v3（artifact version id 79cc5f40-887c-476e-9d6d-bbdea1916f2e）于 2026-09-16T07:16:57.362Z 的 quick review 立刻返回 15 个 CITATION_EVIDENCE_ALIAS_UNRESOLVED。
3. packages/provenance/src/computation-review.ts 中，quick check 直接以当前 version.references 按 alias 查找；找不到或不是 evidence 就生成该 finding。
4. packages/provenance/src/recorder.ts 的 declareWorkspaceArtifact 只写入本次 run 的 referencesProvider drain 结果。若修订只编辑文本、未重新调用 declare_claim，新版本没有可 drain 的 chip map；现有上一版本 reference 不会自动继承。
5. services/api/src/runs/index.ts 也明确说明 declare_evidence 本身不入 chip buffer，只有 declare_claim 的 chip_map 会进入 buffer。因此正常“根据 review 文本修订”路径很容易复现。

建议修复方向：在 report 新版本创建后，基于当前内容提取 [evidenceN] alias；将上一版本中同 alias、kind 为 evidence 的 references 与当前 run 新声明的 references 合并、去重后保存。优先使用当前 run 的新 mapping，并为以下场景补回归测试：

• v1 有 evidence chips，v2 仅修改无关文字且保留 markers：v2 必须仍有 chips；
• v2 删除某 marker：不能继承被删除 marker；
• v2 为同 alias 重新声明证据：必须使用新 mapping；
• 并发主 Lead/子 Agent context 不得串用 chips。

版本信息

• UI 中同一 report 已生成 v1–v7；问题发生在 v2 deep review 后的首个 v3 修订版本。
• Reviewer log：.sciencediscovery-data/logs/reviewer-specialist.ndjson
• Memory graph log：.sciencediscovery-data/logs/memory-graph.log