【提案】 显式标记空 Todo 状态避免继续对话冲突

[Yumiue]

目标问题（Why）

• 当前痛点：继续对话时，如果上一轮已经清空或完成 todo，context builder 会省略 Todo State 区块，模型无法明确区分“没有待办”和“旧待办仍可沿用”，容易在后续推理中继续写入已清空的 todo，形成 todo conflict。
• 触发场景：用户继续已有会话，todo 列表为空或全部处于终态；runtime 进入验证后仍可能回到执行阶段处理补充动作。

设计方案（How）

• 核心设计：当 internal/context 的 todo source 没有活跃 todo 时，仍输出 Todo State: None，把“无活跃 todo”作为显式上下文状态传给模型。
• 关键机制：同时覆盖空列表与全部终态两个边界，避免通过省略区块表达状态；在 runtime/controlplane 允许 verify -> execute 转换，支持验证阶段发现仍需执行时回到执行态。
• 边界与非目标：本提案不改变 todo 的持久化结构、不新增工具能力、不调整 TUI 展示协议，也不把 todo 状态散落到 UI 层。

落地清单（What）

• internal/context/source_todos.go 在无活跃 todo 时输出 Todo State: None
• internal/context/source_todos_test.go 覆盖空 todo 与全部终态 todo 的显式输出
• internal/runtime/controlplane/phase.go 允许 RunStateVerify 回到 RunStateExecute
• internal/runtime/controlplane/phase_test.go 覆盖 verify -> execute 合法转换

验收标准（Done）

• 空 todo 输入时，context builder 返回单个 Todo State 区块且内容为 None
• 全部终态 todo 输入时，context builder 返回单个 Todo State 区块且内容为 None
• control plane 接受 verify -> execute 状态转换
• go test ./internal/context ./internal/runtime/controlplane 通过

风险与回滚

• 风险：系统提示中会固定出现 Todo State: None，可能略微增加上下文 token；但该状态能消除继续对话时的歧义，收益高于成本。
• 回滚方案：如发现模型对 None 语义处理不符合预期，可回滚 context 输出逻辑与 verify -> execute 状态转换，恢复为无活跃 todo 时不输出区块。

[Yumiue]

补充根因分层与修复状态：

• Runtime 侧在新用户 run 边界已经会清空/裁剪旧 todo，并发出 todo_snapshot_updated reset 快照。
• context 侧已把无活跃 todo 显式呈现为 Todo State: None，避免模型把“无 todo”误解为可沿用旧 todo。
• Prompt 侧已同步 build execution 规则：缺失 Todo State 或 Todo State 为 None 时，都要求先创建当前 run 的 required todos。
• Web 侧追加修复：reset/空 todo snapshot 会清理面板里的 stale todoConflict；普通 conflict 后的 snapshot 仍保留冲突提示，避免同一失败操作被立即抹掉。

已在 PR #691 补齐，验证命令：

• go test ./internal/context ./internal/runtime/controlplane ./internal/promptasset
• npm --prefix web test -- useRuntimeInsightStore eventBridge