feat(asr): 本地语音转写接入为一级路由 + 并行工作流合并提交

按用户指示做**一包提交**，不按工作流拆分。本提交刻意混合了多条并行线：

  · 本地 ASR 接管：audio 成为与 chat/embed/image/video 同等的路由类别
    （IsLocalRoute 单一判据、audio 健康探测、default_audio_route、
    auto 占位、GET /api/ai/routes/audio、回退云端时界面明示「音频已出网」）
  · LLM 调用层：ctx 贯穿、ToolCall/ToolSchema、EmptyCompletionError /
    TransientUpstreamError（按错误类型而非文案判重试）
  · 编排 Agent：general_assistant orchestrate/persistence/spec_driver
  · 联网搜索：internal/search（playwright）
  · 网盘：backend + 前端
  · 前端 UI：导航/路由/工作台若干页
  · 交付文档：DELIVERY.md / AR04 / 部署文档的「无 Python」表述据实改写，
    新增 eai_agentplatform-asr.service、asr.env、clonezilla-cleanup 清 ~/asr-poc

不分拆的原因：dev 早期，粒度不该打断工作节奏。且实测过——这些改动
**在编译上是同一个单元**（llm.go 的 ctx 签名变更牵动 12 个调用点，
chat_message.go 的 ctx 改动又与编排重写同处一个 hunk），拆出来的中间态编不过。
详见 TOP_CODING_RULES.md G14.5 与 bugs_and_errors.md E09。

Co-Authored-By: Claude Code <noreply@anthropic.com>

test/general_assistant/run_18/request.json

@@ -0,0 +1 @@
+{"message": "请写一份关于\"人形机器人产业链上中下游\"的分析报告，重点包括上游核心零部件、中游整机制造、下游应用场景，并对比国内外主要玩家。","specialist_key":"general-assistant","mode":"chat","stream":false}

test/general_assistant/run_18/summary.md

@@ -0,0 +1,32 @@
+# run_18（编排路径 · 重度搜索型 · 预算放宽后）
+
+- 用例：`message="请写一份关于\"人形机器人产业链上中下游\"的分析报告，重点包括上游核心零部件、中游整机制造、下游应用场景，并对比国内外主要玩家。"`
+- 意图：**orchestrated**（产业链/上中下游/对比 → 强编排信号）
+- 跨预算验证：150s → 240s（`overallTimeout` 放宽），并加宽 worker 死循环收敛阈值（`toolRounds >= 5`）
+- 结果：⚠️ **HTTP 200，240.0s**（踩新的 240s 兜底边界返回），6.4KB
+- 时间：2026-09-25 22:12:38
+
+## 两次对比
+| 项 | 预算150s（run_18首次） | 预算240s（本次） |
+|---|---|---|
+| 收敛 | 150s 兜底 | 240s 兜底 |
+| 产物 | S1 框架 + 4.6KB | S1 框架（更完整、含玩家清单/章节大纲）+ 6.4KB |
+| worker 报告 | S2-S6 空 | S2-S6 仍空 |
+
+## ai_call_log（关键诊断）
+- 338：planSubTasks 拆解 19.3s success；
+- 339：主编排 240.0s；
+- **⚠️ worker 一条 `text_gen` 记录都没有**——说明 5 个 worker 的 `agent.Run` 均未跑完返回（runOne 未落日志），worker 卡在首轮/多轮 `generateWithTools` 的 HTTP 等待中，直到编排 ctx 截止。
+
+## 根因判断（重视）
+路由 `chat_route_lmuai_deepseek_v4_flash` 的 `timeout_seconds: 90`。run_18 的 worker prompt 属「长输入、报告型」，3 个 worker 并发发起时 LLM 服务端响应极慢/挂起，单次调用逼近 90s 仍无返回，多轮叠加远超编排预算 → worker 无法在预算内写出报告。
+- 这不是「编排空回复/死循环」逻辑问题（对比 run_14 HTTP 对比 94s 正常完成、run_16/17 优秀）；而是 **LLM 服务端对「长 prompt + 并发报告型」请求的响应能力/排队**导致单次调用卡满 timeout。
+
+## 编排侧已尽力的优化（本次已改）
+1. `overallTimeout` 150s → **240s**，给重度搜索型 worker 更多写稿预算；
+2. `RunWithUsage` tool 死循环收敛由「仅纯工具轮统计」放宽为「工具轮数 >= 5 即收敛」，并在历史含搜索素材时用无工具纯文本重生成结论。
+
+## 待决策（超出「修」范围）
+- **调用级超时**：给编排 worker 的每次 `generateWithTools` 设一个更短的调用超时（如 30s），使慢调用快速失败、跳过该类 worker，避免单个慢 LLM 拖死整个编排；
+- **路由/并发**：评估为编排 worker 换一条对长 prompt 响应更稳的路由，或降低 `maxConcurrent`、减少长 prompt 并发排队；
+- **预算再放宽**：若接受更长等待，可把编排预算提到 300s+，但需权衡用户体验。