自动会话标题生成反复 60 s 超时并与首个模型步骤争抢，失败后静默降级为截断标题

[ewanchen0314-boop]

Title: 自动会话标题生成反复 60 s 超时并与首个模型步骤争抢，失败后静默降级为截断标题

Labels: bug, performance

===== 以下为 Issue 正文 =====

现象

被排查的会话启动时，宿主日志记录：

[W] [session-title-service] session "session-…": automatic title generation failed:
    TimeoutReason: SESSION_TITLE_TIMEOUT after 60000ms

同一台机器上的多个会话在相近时段内连续出现该超时（一次观察窗口内至少 4 个不同会话）。

影响

1. 标题静默降级：超时后 session/title 事件带上 source.kind: "fallback"，标题变成首条用户消息的机械截断（例如一个长类名被腰斩成 com.example.foo.modules.servic），用户不知道为什么标题这么奇怪，也看不到"生成失败"的原因。
2. 与首步争抢：该 LLM 请求与会话第一个模型步骤同时发出。实测被排查会话的首步模型耗时 125.7 s，而同一会话其余步骤的模型耗时只有 1.2–6.9 s——首步是唯一与标题生成请求重叠的一步。

环境

• @deepseek-ai/dsh 0.1.5-rc.2，dsh-plugin-desktop 2.0.10
• Windows 11 build 26200 AMD64，16 核 / 29.7 GB / SSD
• 主模型与标题生成走同一个 OpenAI 兼容网关；同窗口内该网关对其他请求也表现拥塞

期望 vs 实际

• 期望：标题生成不阻塞、不拖慢会话首步；失败时降级路径对用户可解释。
• 实际：标题生成占用了与首步相同的 provider 通道，并在 60 s 后静默失败，只留下一条 [W] 日志。

建议

1. 让标题生成请求避开首步：等首步模型往返完成后再发，或明确走低优先级/独立连接。
2. 把 60 s 超时值做成可配置项，并允许直接关闭自动标题生成。
3. 降级为截断标题时，在 UI 上给一个轻量可见的原因提示（"标题自动生成失败，已使用首条消息"），而不是让用户以为产品就是会生成这种被腰斩的标题。