TeleportController 重构 · 第二次：流程命令化与 V2 拆分

本次挂在 CL856231（pending，2026-10-12）：把传送编排从「大段回调 + 代次标志」改为「分阶段命令（Command）」驱动，并把 4371 行的 V2 表现单体拆成流程、组装器、命令与协作类。变更共 40 个文件：24 增、15 改、1 删。

1. 背景与目标

第一次拆分解决了「控制器太大」，但每条表现路径内部的阶段推进仍写成连续回调：成功、让位、失败、致命四种收口散落在各处，阶段之间缺少统一边界；V2 表现层 TeleportV2Flow.ts 单体达 4371 行，改一处要通读全文件。第二次重构做两件事：把阶段推进收敛为命令（单阶段只回答「成了没有」），把 V2 单体按职责拆开（流程持状态、组装器给计划、命令做阶段、协作类管资源与绑定）。

2. 文件变更总览

关键行数变化（本次实测）：

3. 命令层：四出口与轮次身份

阶段命令统一继承 TeleportCommandBase<T>，只固定两件事：阶段名（日志前缀 传送-阶段[名]）与四个收口出口——Complete（成功继续）、Skip（主动让位）、Abort（失败还原）、FatalError（致命终止）。四者都先判 Executing 才结算，避免迟到回执重复收口。

命令之间通过 TeleportCmdContext 共享本轮状态（传送类型、参数、是否主控），并携带 TeleportRoundToken 做轮次身份隔离：每轮新建、取消后永不复用；异步等待抓到令牌后，回执到达时用 IsRoundValid 自检，不成立就 Skip 让位。命令只依赖受限接口 ITeleportStageFlow，不反向依赖流程实现——这也是它能在两套流程里复用的原因。

命令层的完整机制（四出口语义、上下文与令牌、InvalidateFlow 收口、异步「先监听再启动」）见 命令模式专栏 · 案例二 · 传送的 cmd，本文不重复。

4. 默认路径：SeqV1 完整链与 Simplified 简化段

默认线由 TeleportTransitionFlow 驱动，一个阶段一个 CommandExecutor：SeqV1 完整链用 SeqV1Executors: Set 记账，简化段用单个 SimplifiedExecutor。是否走 SeqV1 由 ShouldUseSeqV1Commands() 判定（非系统 Loading 且非淡入淡出传送）。各阶段组装命令如下：

每个 executor 设 EnterSeqBackstopTimeoutMs（40 秒）作为兜底超时，正常结束时在 finally 里 RemoveExpireTime() 撤掉——是「显式设超时 + 用后移除」的正面用法，不依赖框架默认（框架默认超时只打日志、不结算）。取消整轮时 InvalidateFlow() 会作废旧令牌、换新令牌，并对挂起的流送等待与仍在跑的 executor 分别兑现与 CommandBail()。

5. V2 线：单体拆分

V2 表现（飞天遁地 / Seq 过场）是独立的第二条线，由 TeleportController 上的 UseTeleportV2Flow 开关接入（默认 false，即默认走上面的 SeqV1 / 简化线）。V2 线把旧单体拆开：

V2 过场衔接的时序（Seq2 循环退出到 Seq3 起播的 7 个阶段与实测耗时）见 V2 表现 · Seq2 → Seq3 衔接问题。

6. 保留的不变量

• 外部入口不变：调用方仍通过 ControllerHolder.TeleportController 使用原有公开方法，命令化没有改变门面签名。
• 默认路径不变：UseTeleportV2Flow 默认 false，默认仍走 SeqV1 完整链 / 简化段。
• 表现分流不变：无缝、黑屏、系统 Loading、SeqV1 / SeqV2 与模拟端六种表现形式继续保留。
• 协议与安全收尾不变：同场景 LoadDone 语义、地面确认、遮罩所有权、Seq3 成组恢复等来自第一次重构的不变量继续成立。
• 日志口径不变：日志继续带 传送- 前缀，阶段命令统一用 传送-阶段[名]，便于按同一关键词复测。

7. 验证状态与已知遗留

以下四项为代码审查阶段发现的遗留，不是本次重构本体的既定结论，均待修复 / 待确认：

除以上四项外，默认（非 V2）路径未发现 P0 / P1 级问题。