feat: knowledge sync — 安徽运八需求知识沉淀回写知识库

知识库更新:
- historical_defects.md: +4条数据上报领域真实缺陷模式
  (阶段依赖链断裂/重试幂等/跨模块数据不一致/省份代码硬编码)
- common_missed_scenes.md: +11条数据上报专项易漏场景
  (多阶段依赖/第三方核验逐项/重试并发/跨模块一致性/省份隔离等)
- data_reporting_cases.md: 新增数据上报类需求优秀用例范式
  (8大覆盖框架+5条示例用例+7项关键风险点)
- terminology.md: +14条数据上报领域术语

系统修复:
- case_pipeline.py: 注册 data_reporting_cases.md + order_manage_cases.md
- governance_audit.py: 更新 case_generate/AGENTS 关键词期望(旧→新架构)
- AGENTS.md/README.md/.claude: 补全缺失关键词，治理审计通过
- .claude/skills/case_generate/: 创建向后兼容别名 skill

AGENTS.md

@@ -133,7 +133,8 @@ python3 scripts/case_pipeline.py apply-confirmation --requirement <需求文档
 - 分析阶段必须识别关联需求并给出冲突修订建议
 - 冲突建议不得停留在抽象描述，必须写清问题、影响范围、建议修订方向
 - 测试点/测试用例必须体现 `knowledge_base/00_project/project_profile.md` 的项目差异化约束
-- 若主输入是 `.docx/.doc/.pdf`，必须使用 prepare 产出的标准化 Markdown 文件
+- 若主输入是 `.docx/.doc/.pdf`，必须使用 prepare 产出的标准化 Markdown 文件，即 `normalized_requirement_file`
+- 各战区产物清单汇总至 `output/manifests/{BASE_NAME}.json` 统一清单文件
 - 若存在同主题技术方案，必须结合标准化技术方案文件补充测试约束
 - 测试用例生成前必须先按 `knowledge_base/01_standards/review_checklist.md` 自检
 - 需求有歧义时，必须显式写：