涉及文件： topic_api.py、subscriber_progress.py、node_runtime.py、flow_run_observation_contract.py
问题描述：
flow run 的主干路径（提交 → 执行 → request_done → subscriber_done → 输出读取）已经有一定实现基础。但以下边界场景仍缺少明确的处理路径，容易出现状态残留或行为不一致：
- 取消路径（cancellation）：
cancel_flow_run 调用后，相关的 event_chain、subscriber_progress、输出缓冲区的清理时机不明确。取消信号发出后，如果 operator 已经在处理中，是否等待当前 packet 处理完成？超过等待窗口后如何强制清理？
- 超时路径（timeout）：flow run 没有 SLO 超时的主动检测机制，也没有将超时与 flow run 状态机（
running → timed_out）关联的逻辑。normalize_flow_run_request_delivery_status 中 "timed_out" 状态仅在 run_status 为该值时被推导，但 run_status 的来源不清晰。
- 异常结束后的清理：operator 执行抛出未捕获异常时，
RunOutputError 会被写入观测流，但关联的 subscriber_progress 和 event_chain 状态是否一致清理并未得到保证。可能出现 subscriber_progress 显示"running"而 flow run 实际上已失败的情况。
- 临时状态（transient state）的释放：用于
in-flight packet 的临时状态（per-request 的上下文、event group ledger 中的条目）在 flow run 正常完成后应按时释放，当前 gc_idle_runtime_state 仅按空闲时间进行被动 GC，对于高负载场景下在请求完成后主动清理的路径没有明确实现。
任务目标： 让 flow run 的取消、超时、异常结束和正常完成四种结束路径都有明确的清理行为，避免长时间运行后由于残留状态导致的内存泄漏和状态不一致问题。
完成标准： 取消、超时、异常结束三种结束路径有明确的 subscriber_progress、event_chain、临时状态的清理行为，running 状态在 flow run 实际结束后不会持续残留。
父 Issue: #1484
涉及文件：
topic_api.py、subscriber_progress.py、node_runtime.py、flow_run_observation_contract.py问题描述：
flow run 的主干路径（提交 → 执行 →
request_done→subscriber_done→ 输出读取）已经有一定实现基础。但以下边界场景仍缺少明确的处理路径，容易出现状态残留或行为不一致：cancel_flow_run调用后，相关的event_chain、subscriber_progress、输出缓冲区的清理时机不明确。取消信号发出后，如果 operator 已经在处理中，是否等待当前 packet 处理完成？超过等待窗口后如何强制清理？running→timed_out）关联的逻辑。normalize_flow_run_request_delivery_status中"timed_out"状态仅在run_status为该值时被推导，但run_status的来源不清晰。RunOutputError会被写入观测流，但关联的subscriber_progress和event_chain状态是否一致清理并未得到保证。可能出现subscriber_progress显示"running"而 flow run 实际上已失败的情况。in-flight packet的临时状态（per-request 的上下文、event group ledger 中的条目）在 flow run 正常完成后应按时释放，当前gc_idle_runtime_state仅按空闲时间进行被动 GC，对于高负载场景下在请求完成后主动清理的路径没有明确实现。任务目标： 让 flow run 的取消、超时、异常结束和正常完成四种结束路径都有明确的清理行为，避免长时间运行后由于残留状态导致的内存泄漏和状态不一致问题。
完成标准： 取消、超时、异常结束三种结束路径有明确的
subscriber_progress、event_chain、临时状态的清理行为，running状态在 flow run 实际结束后不会持续残留。父 Issue: #1484