[Copilot] Add edit, retry, regenerate, and conversation branching without overwriting history

[helsome]

Background

金融研究对“回答是怎么得到的”有较高可追溯要求。用户编辑历史问题、重试失败消息、regenerate 回答或从某一轮 fork 新方向时，不能简单覆盖旧消息，否则 citations、tool activity、run manifest、evaluation 和历史结论都会失去上下文。

需要把 conversation evolution 设计成显式、可追踪的 branching model。

Related: #13 #21 #27 #29 #30 #33

Requirements

Message/run identity

• 每条 user/assistant message 有稳定 id；
• assistant generation 与具体 run id 绑定；
• edit/regenerate/retry 不覆盖原始 artifact；
• branch/fork 有明确 parent message / parent branch relation。

Operations

至少支持：

• edit user message and rerun from that point；
• retry failed/cancelled run；
• regenerate assistant answer；
• fork conversation from an earlier turn；
• switch between alternative branches/answers。

Semantics

• 编辑历史消息后，新 branch 不应错误继承后续旧回答；
• regenerate 使用同一 user context，但创建新 run/manifest；
• retry 对失败 run 明确区分“继续/重试”和“全新 generation”；
• citations/evidence/tool activity 必须属于各自 generation，不能在分支之间串线；
• Watchlist/Portfolio 等 context snapshot 若参与回答，应记录当时版本。

UI

• 用户能看出当前所在 branch；
• 多个 regenerate 结果可切换；
• 历史 branch 可返回，不因编辑永久丢失；
• branch UI 不需要复杂 Git 图，但关系必须可理解。

Acceptance Criteria

• edit/retry/regenerate/fork 四类操作都有明确数据语义。
• 原始消息和回答不会被 destructive overwrite。
• 每次 regenerate 都创建独立 run id / manifest / evidence set。
• branch 切换不会混入其他 branch 的 citation/tool state。
• reload 后 branch history 仍可恢复。
• 对 failed/cancelled message 能从 UI 发起正确 retry。
• PR 必须用真实 Copilot 任务演示：生成回答 → regenerate → 编辑早期问题 → fork → 在两个 branch 中产生不同工具/evidence，证明历史与引用完全隔离。

Non-goals

• 不要求实现多人协同编辑。
• 不要求建立通用版本控制系统；重点是 conversation/run lineage。

[CC1227871]

/claim

[github-actions]

@CC1227871 已认领该 Issue，并已自动设为 Assignee。提交 PR 时请在描述中写 Closes #34。