fix: preserve pending research after corrections / 修正后保留待处理资料

[harr1sz]

English

Problem and fix

Ingest research, then submit a correction before distilling it: the correction version currently includes every stored material in its manifest. The next briefing therefore treats that research as already processed and omits it. Promoting a relayed correction has the same effect. The material remains on disk, but drops out of the pending workflow.

Build each correction version from its selected content baseline plus the correction material. Use that same set for the version manifest, hash, count, and quality. Keep the complete material set in subject state and calculate the pending delta against the new current version. This preserves unprocessed research for the next briefing and evidence-checked commit.

The change stays inside the existing SQLite transaction and adds no dependencies, public fields, or schema migration. Exact RequestId replay remains unchanged. It applies to future corrections; it does not rewrite historical versions or repair material already treated as consumed by the old behavior.

Five regression scenarios cover direct and promoted relayed corrections, with and without a current profile, plus correction of an active candidate when a current profile exists. They check stale leases, replay after reopening storage, and a subsequent commit citing the original research. Existing zero-delta behavior is retained when no research is waiting. Architecture and generated design documentation are updated to match.

Validation

Node 22.22.1, pnpm 10.32.1, Python 3.9.6:

• Build, typecheck, formatting/lint, documentation verification, and git diff --check: passed.
• Full test pipeline: 1,002 Vitest tests, Panel browser check, 49 package-boundary tests, and 34 build-artifact tests passed. The final Python step hit an environment conflict: a user-installed tests package shadowed this repository. Running PYTHONNOUSERSITE=1 pnpm run test:plugins passed all 13 tests without changing repository code.
• All five new scenarios failed with the original membership logic and passed with the fix. A rebuilt-engine reproduction now returns the original source in brief.materials with addedMaterialCount=1; the original returned an empty list and zero.
• Independent source review found no blocking issue. Full release gates, coverage, hygiene, and real-host/model acceptance were not run.

This PR targets distilly-plugin. Legacy duplicate-creation protection remains in #145. Oversized briefing recovery (#149) is a separate change.

中文

问题与修复

先录入调研资料、再提交修正时，当前实现会把全部已存资料写入修正版本的 manifest。下一次 briefing 因此把尚未蒸馏的调研当成已处理内容，直接略过。转述修正经审核提升为当前版本后，也会触发这个问题。资料仍在磁盘中，但从后续待处理流程里消失了。

修正版本现在只包含所选内容基线已经使用的资料，以及本次修正资料；版本的 manifest、hash、数量和质量计算统一使用这个集合。人物状态继续保留完整资料集合，待处理增量则与新的当前版本比较。这样，未处理的调研会继续出现在下一次 briefing 中，并可用于正常的证据校验和提交。

修改仍在原有 SQLite 事务内完成，不增加依赖、公共字段或数据库迁移，也保留相同 RequestId 的精确重放行为。修复对后续修正生效，不重写历史版本，也不自动恢复此前已被误判为处理完成的资料。

新增五个回归场景，覆盖有无当前 Profile 时的直接修正和转述修正提升，以及已有当前 Profile 时对活动候选版本的修正。测试检查旧租约失效、重开存储后的请求重放，并实际提交引用原始调研资料的下一轮结果。没有待处理调研时，原有零增量行为保持有效。架构说明与生成的设计章节也已同步。

验证

环境：Node 22.22.1、pnpm 10.32.1、Python 3.9.6。

• 构建、类型检查、格式与 lint、文档校验、git diff --check 均通过。
• 全量测试中的 1,002 个 Vitest 测试、Panel 浏览器检查、49 个包边界测试和 34 个构建产物测试通过。最后的 Python 步骤因本机已安装的 tests 包遮蔽仓库模块而失败；使用 PYTHONNOUSERSITE=1 pnpm run test:plugins 重跑后，13 个测试全部通过，无需修改仓库代码。
• 五个新增场景在原逻辑下失败，修复后通过。重新构建后的复现结果为 addedMaterialCount=1，且 brief.materials 包含原始资料；原逻辑返回零和空列表。
• 独立源码审查未发现阻塞问题。未运行完整发布 gates、覆盖率、hygiene 或真实宿主／模型验收。

目标分支为 distilly-plugin。旧版重复创建保护仍由 #145 处理；超大 briefing 恢复（#149）单独提交。