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`，并按测试前状态恢复车身设备。

docs/workflows/t2g-seat-hardware-bench.md

@@ -43,12 +43,13 @@ powershell -ExecutionPolicy Bypass -File .\tools\build_seat_firmware.ps1
 - 热管理命令：`0x29E/0x3CE`；档位反馈：`0x4FA`。
 - 移动命令：`0x300`；系统 ACK：`0x301`；归一化位置：`0x302`；Hall/量程：`0x303`。
 - 电流诊断：`0x304` 四轴轮询，`0x305` 通风/加热；动态模式：`0x306` 以100 ms周期报告模式、阶段、循环和活动轴。这些诊断值用于台架可见性，当前保守阈值不能替代外部限流或量产保护。
+- 固件身份：`0x307` 以500 ms周期报告 `SMV8`、revision、build、轴数量和协议版本；当前仓库镜像为 revision 15 / build 16。
 - Opcode 1 的 `ParamA` 为 1–10000 绝对位置；后端显式发送 30 s 超时覆盖值。
 - 前端目标 `0%`/“归零”不是普通绝对位置，而是 `HOME_KNOWN_RANGE (0x0B)`；只有收到 `COMPLETE/OK`、Near、Hall≤2 和 PositionValid 才算成功。
-- Opcode 3 的 `ParamA` 为持续时间，`ParamB` 为驱动等级×10（默认 90%）。
+- Opcode 3 的 `ParamA` 为持续时间，`ParamB` 为驱动等级×10。M0–M2 默认 90%；M3 腿托按当前台架实测使用 50%，避免高占空比下执行器保护导致 Hall 停止和请求超时。
 - `STOP_ALL` 的专用 ACK 为 4；完成/故障 TaskState 分别为 6/7。
 
-新版固件把 `0x304/0x305` 用于电流诊断，并用`0x306`报告原生动态模式，不能继续发送旧版身份请求。后端在任何控制帧之前被动观察 `0x301–0x306`、`0x4FA`、四个 MotorID、固件 revision 13 和各轴标称 MaxHall（允许 5% 台架差异）；真实硬件执行启用后，未观察到完整签名会自动使用仓库内 IAR 镜像烧写，重新被动验证成功后继续原请求。烧写或复验失败时禁止发送座椅控制帧。
+新版固件把 `0x304/0x305` 用于电流诊断，用 `0x306` 报告原生动态模式，并用 `0x307` 提供不可与旧 revision-15 镜像混淆的 build 身份。后端在任何控制帧之前被动观察 `0x301–0x307`、`0x4FA`、四个 MotorID、固件 revision 15、build 16 和各轴标称 MaxHall（允许 5% 台架差异）；真实硬件执行启用后，未观察到完整新鲜签名会自动使用仓库内 IAR 镜像烧写，重新被动验证并执行四轴位置同步后继续原请求。烧写或复验失败时禁止发送座椅控制帧。运行外部单电机测试脚本后无需手工恢复生产固件，但下一次硬件请求会包含一次自动烧录和位置同步，首条请求耗时会相应增加。
 
 ## 启用配置