[功能]ChatHarness 已实现但未接入主链路，存在两套 harness 概念

[atoncooper]

📌 概述 / 问题描述
项目中同时存在两个名为 "harness" 的概念：app/harness/AgentHarness（生产正在使用，基于 ToolRegistry + AgentRuntime）与 app/services/rag/harness.py::ChatHarness（planner-driven RAG dispatcher，带 reasoning_steps、scope hints、stream
支持）。ChatHarness 通过 app/services/chat/harness.py::build_harness() 构造并对外导出，但实际 orchestrator
完全没有调用它，是一段未接入的"半成品"代码。

🔁 复现步骤

1. 在仓库根目录执行 grep -rn "build_harness|ChatHarness(" app/ --include="*.py"。
2. 检查所有 /chat/ask* 端点的实际调用链路（app/services/chat/orchestrator.py → dispatcher.agent_run →
   agent_harness.dispatch）。

🎯 预期结果
仓库内只保留一个 chat harness 概念，命名清晰、调用方明确。如果 ChatHarness
是替代方案，应至少有一个端点真实接入；如果已废弃，应删除以避免歧义。

❌ 实际结果

• build_harness 仅在 services/chat/init.py 被导出，无任何运行时调用。
• 两个 harness 命名相近，新人 / AI 助手容易在修改时定位错误（违反 CLAUDE.md 第 2.6 节定位索引）。
• ChatHarness 内置的 planner-loop / scope filter / stream 协议成为悬空实现。

⚠️ 严重程度 / 影响
P2 - 中（架构债务，阻碍后续 chat 能力扩展，新人易踩坑）

💻 环境与上下文

• 受影响文件：app/services/rag/harness.py、app/services/chat/harness.py、app/services/chat/orchestrator.py、app/servi
  ces/chat/init.py
• 分支：feat/cloud-pdf-and-ui