背景
架构文档已将“用户取消”定义为 runtime 的停止条件，但当前实现里 runtime 没有把取消作为独立终态处理，上层也缺少可稳定关联一次运行的事件标识。这会导致两个问题：
运行被取消时容易被当成普通错误处理。
后续 TUI 接入取消能力时，旧运行的晚到事件可能污染新运行状态。
这次只收敛 internal/runtime，不改 TUI 入口和展示。
目标
在 runtime 层明确“取消不是错误”
让上层只通过可取消 context 就能终止当前运行
为每次运行补 RunID 透传，方便上层做事件归属过滤
不改变现有 TUI -> Runtime -> Provider / Tool 分层
行为约定
用户取消后，runtime 终态事件应为 EventRunCanceled
取消不应额外产生 EventError
已经发出的 chunk/tool start 事件允许保留
runtime 不提供 Cancel() 接口，取消入口仍然是调用方传入的 context.Context
非目标
不实现 TUI /cancel 命令或快捷键
不处理取消后的 UI 状态文案、transcript 展示
不调整 session 持久化策略
背景
架构文档已将“用户取消”定义为 runtime 的停止条件，但当前实现里 runtime 没有把取消作为独立终态处理，上层也缺少可稳定关联一次运行的事件标识。这会导致两个问题：
运行被取消时容易被当成普通错误处理。
后续 TUI 接入取消能力时，旧运行的晚到事件可能污染新运行状态。
这次只收敛 internal/runtime，不改 TUI 入口和展示。
目标
在 runtime 层明确“取消不是错误”
让上层只通过可取消 context 就能终止当前运行
为每次运行补 RunID 透传，方便上层做事件归属过滤
不改变现有 TUI -> Runtime -> Provider / Tool 分层
行为约定
用户取消后，runtime 终态事件应为 EventRunCanceled
取消不应额外产生 EventError
已经发出的 chunk/tool start 事件允许保留
runtime 不提供 Cancel() 接口，取消入口仍然是调用方传入的 context.Context
非目标
不实现 TUI /cancel 命令或快捷键
不处理取消后的 UI 状态文案、transcript 展示
不调整 session 持久化策略