Paired: GitHub #217 ↔ GitCode !2126

What type of PR is this?

/kind feature

What does this PR do / why do we need it:

本 PR 为 scheduled dispatch 模式引入按需临时 reviewer harness，将 reviewer 与 teammate 解耦。

核心改动：

• Scheduler：新增 _spawn_temp_reviewer 方法，为 create_task(reviewer=[...]) 中写入的每个 reviewer 名称构建一次性的 TeamHarness。harness 继承团队的 base agent spec（模型、文件系统工具）加 verify_task + view_task 工具，调用 run_once() 后立即 dispose——不写 DB member 行、不走 CoordinationKernel、不走 UNSTARTED 状态机
• Fire-and-forget 派发：reviewer harness 通过 asyncio.create_task 作为后台任务启动，同一任务的多个 reviewer 并发执行，不阻塞 scheduler 扫描循环
• 校验放宽：create_task 中 reviewer 名称不再需要是已有 team member。scheduler 自动为非 member reviewer 名称创建临时 harness
• 生产日志：新增 [judge]、[verify_task]、[verify_vote] 日志，方便生产环境追踪投票状态和 reviewer 输出
• 提示词全面更新：新增 reviewer.md 系统提示词（中英文）。重写 dispatch_scheduled_leader.md 中的验证者分配决策段，改为基于任务类型的分配规则（调研类→3名、设计类→3名、实现类→2名等）。新增验证流程与验收交接说明。在 leader_workflow 系列文件中加入模式感知引用。回退模式无关文件中的 reviewer 特定描述，避免污染 autonomous dispatch 模式
• Otel 可观测性：temp reviewer harness 通过 RailSpec 注入 otel rail，产出 agent 级别 span，可在 trace 文件中查看 reviewer 的完整推理链和工具调用

Which issue(s) this PR fixes:

Fixes #（你的 issue 号）

What scenarios were tested, and what were the verification results（Function, performance, reliability, etc.）：

• 单元测试：test_team_scheduler.py（25 个用例）和 test_review_voting.py（11 个用例）全部通过。Judge 判定数学、投票记录、settle pass/fail、round 隔离、tally 聚合均验证正确。其中 2 个调度器测试和 1 个工具变体测试的断言已根据新的 reviewer 模型更新
• 端到端手动测试：启动 jiuwenswarm scheduled 模式，创建团队和携带 reviewer 角色名（如"正确性审查"、"代码质量审查"、"性能验证"）的任务。使用 DeepSeek-v4-pro 模型，验证：
  • temp harness 正确构建和 dispose（日志显示 [reviewer_finish] 带验证报告输出）
  • reviewer 正确调用 verify_task 投票（身份守卫通过 reviewer 专属 TeamTaskManager）
  • 投票正确写入 DB，tally 正确计算
  • judge() 正确判定 pass/fail/undecided（包括多 reviewer 并发场景）
  • 多个 reviewer 并发执行（fire-and-forget 非阻塞，日志同时显示多个 spawning temp harness）
  • leader 按照新的任务类型规则正确分配 reviewer 数量和验证角度
  • Otel trace 文件可正常查看 reviewer 的 agent span 和工具调用（view_task、read_file、verify_task 等）

Self-checklist:（Please check carefully,and mark an x in the [] brackets. We will review your completion status.）

• • Design: Has the solution corresponding to the PR been reviewed by the Maintainer, and have all review comments been replied to and revised
• • Test: Has the code in the PR been fully covered by UT/ST test cases, and have the newly added test cases been uploaded to the repository along with this PR or already uploaded.
• • Verification: Does the PR description contains a detailed description of the verification results regarding the achievement of the expected goals for the Feature, Refactor, and Bugfix to this PR.
• • Interface: Does it involve changes to external interfaces? The corresponding changes have been approved by the interface review organization, and the annotation information for the API has been correctly refreshed.
• • Document: Does it involve modifications to the official website documentation? If so, please submit the materials to the Doc repository in a timely manner.

Linked Closing Issues:

• #1435