feat: complete dual-seat whole-vehicle orchestration

docs/workflows/t2g-cabin-dual-channel-can.md

@@ -8,7 +8,8 @@
 
 ## 适配器和通道
 
-一个 `USBCANFD-200U` 只由一个 32 位桥接进程打开一次，再向应用暴露两个通道视图：
+一个 `USBCANFD-200U` 只由一个无界面的常驻 CAN Runtime 打开一次。Runtime
+通过 32 位 ZLG DLL 子进程持有设备，再向自编排与自修复暴露两个通道视图：
 
 | 通道 | 用途 | 帧格式 | 仲裁速率 | 数据速率 |
 |---|---|---|---:|---:|
@@ -21,6 +22,8 @@
 
 ```powershell
 $env:COGNITIVE_AGENT_HARDWARE_EXECUTION_ENABLED = "true"
+$env:COGNITIVE_AGENT_CAN_RUNTIME_BACKEND = "standalone-zlg"
+$env:COGNITIVE_AGENT_SHARED_CAN_RUNTIME_ENABLED = "true"
 $env:COGNITIVE_AGENT_VEHICLE_CAN_ENABLED = "true"
 $env:COGNITIVE_AGENT_SEAT_CAN_BACKEND = "zlgcan"
 $env:COGNITIVE_AGENT_VEHICLE_CAN_BACKEND = "zlgcan"
@@ -40,12 +43,19 @@ $env:COGNITIVE_AGENT_HARDWARE_APPROVAL_TOKEN = "<bench-only-token>"
 
 `副驾座椅通风3档，同时打开空调，温度设为24度，风量3档`
 
-该请求生成独立的 `seat` 与 `native_climate` FunctionConfig/CommandPlan。真实执行时，两组执行器在独立线程中使用 CH0/CH1 通道视图；底层桥接仍统一串行化 SDK 调用，并将长时间接收切成不超过 20 ms 的时间片，以便两个通道交替收发。
+该请求生成独立的 `seat` 与 `native_climate` FunctionConfig/CommandPlan。真实执行时，
+座椅计划通过 CH0 高层任务队列执行，车端计划使用 CH1 通道视图；两组执行器可以并行，
+底层 Runtime 仍统一串行化单次 SDK 调用。CH0 自修复采用非阻塞接收，避免长期占用
+设备锁；旧的直接执行兼容路径仍把阻塞接收切成不超过 20 ms 的时间片。
+
+自修复硬件诊断、四轴归零和六个故障用例同样使用该 Runtime 的 CH0，不再启动
+ZCANPRO。自修复任务与普通座椅任务共享一个队列，因此不会争抢 CH0；CH1 保持同一
+设备所有者并可继续被动接收。固件烧录、设备重启和急停属于设备级维护操作。
 
 ## 验证要求
 
 1. 先运行 `zlgcan_bridge.py --self-test`，确认经典 CAN 与 CAN FD API 导出及 ABI 结构尺寸。
-2. 在 ZCANPRO 确认 CH0/CH1 接线、终端电阻和总线状态正常，然后关闭其在线通道，避免与服务争用设备。
+2. 确认 CH0/CH1 接线、终端电阻和总线状态正常，并保持 ZCANPRO 关闭，避免与 Runtime 争用设备。
 3. 用 dry-run 核对两份计划：座椅报文位于 `seat_can`，车身报文位于 `body_can`；空调控制 ID 为 `0x1DE`。
 4. 以 hardware 模式执行低风险联动句，要求座椅板端反馈成功，且车身通道观测到对应状态反馈（空调为 `0x404`）。仅发送成功而无状态帧不能记为通过。
 5. 验证完成后关闭座椅热舒适功能、发送座椅 `STOP_ALL`，并按测试前状态恢复车身设备。