[Bug] After a provider error, entering an agent’s chat from Home stays on the errored conversation instead of a New Topic state

快速结论：该问题出现在 LobeChat 桌面端（Electron）中：首条消息在使用默认草稿对话时因 Provider 网络错误失败后，返回 Home 再进入同一 Agent，标题显示“New Topic”但消息区仍渲染失败的对话内容。优先排查草稿桶（main_<agentId>_new）是否残留了失败会话的数据，而不是会话路由同步逻辑。

适用环境：LobeChat v2.2.20（canary dfe61e0bc4），Desktop App（Electron / Chromium），macOS，自托管方式并配置了自定义 Anthropic 协议兼容模型 Provider；Web 端也涉及同样的路由同步入口。

最快修复方案：暂无确认的一步修复方案。Issue 中提出的修复方向是：让桌面端 ActiveConversationBridge 的路由投影（projectCoordinate.ts 的 syncConversation）以及 Web 端 useChatRouteSync 的 ChatHydration/syncTopicFromUrl 在把 activeTopicId 置为 null 时，也执行和 switchTopic(null) 相同的草稿桶清理逻辑，而不是直接写 activeTopicId: null 绕过清理。

注意事项：该修复方案在评论中只被描述为“proposed fix”，未见合并或验证记录；清理草稿桶时要注意不要静默删除用户已输入但未发送的内容，Issue 作者也指出这是产品取舍问题。

问题场景

在 LobeChat 桌面端打开某个没有活跃会话的 Agent，发送第一条消息，此时消息进入草稿桶 main_<agentId>_new。若该次请求的 Provider 连接超时或中断，生成失败，不会创建正式 topic，草稿也未被迁出该桶。随后返回 Home，再点击同一 Agent 进入 /agent/:aid（路由中无 topicId），头部虽然显示“New Topic”，消息区却仍渲染上一次失败的对话（用户消息 + 错误卡片）。

报错原文

Connection to the provider timed out or was dropped. Please check your network and try again.
ProviderNetworkError

原因分析

评论中对原分析做了更正：桌面端路由投影本身工作正常，/agent/:aid 会无条件重新投影 activeTopicId === null，store 层并不是原因。真正的问题在于：失败的那次发送发生在 New Topic 草稿状态（main_<agentId>_new），失败后既没有创建 topic，也没有把草稿迁出该桶；重进 Agent 时渲染的空白视图桶里仍保留着这次失败的内容。

进一步追踪发现，通过 switchTopic(null) 进入空白会话的路径会执行草稿桶清理（src/store/chat/slices/topic/action.ts 中“Clear the _new key data … This prevents stale data from previous conversations showing up”），但两个重进入口——桌面端 ActiveConversationBridge 路由投影（projectCoordinate.ts 的 syncConversation）和 Web 端 useChatRouteSync 的 ChatHydration/syncTopicFromUrl——都直接写 activeTopicId: null，绕过了这次清理。这是评论中提出的机制假设。

环境排查

确认客户端类型：该现象主要出现在 Desktop（Electron）构建；Web 构建走 useChatRouteSync，入口不同但同样存在绕过清理的问题。
确认 LobeChat 版本：Issue 基于 v2.2.20 / canary dfe61e0bc4 分析，其他版本行为可能不同。
检查是否使用了自定义 Anthropic 协议兼容的 Provider，并确认该端点会超时或断开连接，这样才容易复现。
观察问题是否只在首条消息（没有已有 topic）时出现；如果已有 topic 后再失败，表现未必相同。
检查该 Agent 的草稿桶 main_<agentId>_new 中是否残留失败消息数据，并确认后续成功发送后残留是否消失。

解决步骤

先按评论给出的稳定复现路径确认现象：把 Provider 指向不可达或很慢的端点，在无活跃会话的 Agent 中发送一条消息，等到网络错误渲染后返回 Home，再点击同一 Agent，观察标题是否为“New Topic”、消息区是否仍有失败内容。
可优先尝试确认草稿桶残留：在能访问 store 或持久化数据的调试环境中检查 main_<agentId>_new 对应消息键下的内容；Issue 评论称该残留会在后续成功发送创建 topic 并迁移消息后消失，可据此验证是否为同一问题。
若准备修复，改动方向是让桌面端 projectCoordinate.ts 的 syncConversation 和 Web 端 ChatHydration/syncTopicFromUrl 在落到空白会话时复用 switchTopic(null) 的草稿桶清理逻辑（参考 src/store/chat/slices/topic/action.ts 对应代码），而不是直接写 activeTopicId: null。
清理策略需明确：Issue 作者建议“进入 Agent 总是从空白聊天开始（方案 A）”，同时保留用户已输入内容作为可恢复草稿（方案 B），避免静默删除用户内容。