fix: unify chat process and reply presentation

docs/agent-chat-ui-design.md

@@ -204,3 +204,15 @@ Agent 形象基于 [Obsidian 原版动画资源](https://ejiidnob33g9ap1r.public
 固定报告字段不变：阶段、结果、结论、边界、数据缺口、证据和建议仍独立校验。新字段通过原有报告 JSON 保存，跟随 revision 与 execution_generation 读取；请求幂等沿用原有机制。旧报告缺省为空，不因缺省字段而产生虚假的报告更新通知。无需数据库表或环境变量迁移。
 
 组件参数唯一来源为前端 `catalog.ts`，导出到 Agent 与 Server；跨字段约束在三端分别验证。Agent `publish_task_report` 使用正式报告通道，聊天 `present_answer` 使用聊天通道。实现与生成命令见 [本地交互式回答](agent-answer-ui.md)。
+
+## 聊天过程与回答恢复
+
+处理过程统一位于回复正文下方。生成中，文字与回答内容块在前，公开执行摘要、标记为过程的内容块和待办在后；最终答复到达或回复流结束后，过程收起为底部“查看处理过程”，入口位于语音播放左侧，没有 `final_answer` 标记的历史回复也遵循同一布局。最终答复明确引用的回答内容块留在主阅读流，其他记录进入处理过程。待回答问题、权限审批和失败状态在正文下方保持可见，不能因回复结束而被隐藏。这里借鉴 Reasoning 的折叠行为，呈现的数据是服务端已发布的过程信息，不额外生成思考文本，也不根据耗时推算完成比例。
+
+最终答复到达后，正文、回复状态与语音/复制操作在同一次交接中切换，网络流的后续收尾不再改变这条回复的展示阶段。输入框仍根据真实执行状态接受引导或排队消息。过程复用生成时的容器和步骤实例，保留工具详情的展开状态；无论用户是否向上滚动或查看过工具详情，交接后默认收起过程并优先让结果正文可读；用户可通过“查看处理过程”重新展开。历史回放直接显示保存的结果，不重新播放交接。
+
+补充问题打断后继续执行时，依据提问记录的 `message_id` 和补充回答的 `delivery.native_message_id` 将前后过程归到续接答复下方；连续补充时沿同一关联链顺序归组。没有正文的旧过程消息不再单独占位，原有正文和用户补充回答仍保留。尚未出现续接答复、历史分页缺少关联消息、仍有待回答问题或审批、关联之间出现新用户请求时，保留原位置。该归组仅影响展示，不改原始记录或消息标识。
+
+生成中、补充后续接和历史恢复共用一个处理过程容器，边框、背景和内边距保持一致；各段执行记录合并为一份列表，不再嵌套另一张“执行进度”卡片。步骤显示身份包含来源消息，避免前后轮次的同名步骤互相覆盖；生成时统一控制整个过程的最近三项与展开全部，完成后由底部入口统一折叠。
+
+已提交的回答以原生用户消息 ID 保存纯净文本和 `data-interaction_reply` 快照，首屏即可还原同一张“已回答”卡片并归组前后过程，不等待独立提问接口。该接口返回较新修订后更新投递状态和重试操作。旧历史由 Agent 按所属会话中已保存的投递 ID 补齐相同表示，不通过文本前缀猜测对应关系，也不改写历史文件。给模型的“用户提交的提问回复”协议前缀只用于推理输入。