拆分自 #2479 TODO 5（性能行为变更，单独 PR，需 benchmark 背书）。

背景

#2479 的受控重测（三臂新基线，PR #2480 与 issue 评论已记录）裁定：CUDA 载体在无 MPS 时 apply_action 惩罚 ~6.5ms（tail-100），吞吐 −32.6%；根因是 collector/learner 双 CUDA context 时间片切换放大了 action 管理路径（scale/clip 等项）每步大量小 kernel 的 launch 延迟。环境级 MPS 只是 NVIDIA-only 的绷带，不能作为代码层默认修复。

TODO

1. 定位并移除 action 路径上的 blocking scalar read / hard sync（apply_action 段，collector 侧 env step 路径），使小 kernel 序列不再被 context 切换放大。
2. 性能行为变更需 benchmark 背书：复用 Work: HOST_BRIDGE CUDA 载体吞吐归因收口——环境级 MPS 观测缺口、旋钮合并与 action 路径根本修复 #2479 的三臂协议（mujoco SAC g1_walk_flat、seed=1、2048 envs、3 blocks × 200 iters、tail-100），无 MPS 的 CUDA 载体臂应追平 CPU 载体基线（参考值：88k vs 67k steps/s，apply_action 0.4ms vs 6.5ms）。
3. ROCm/macOS 无 MPS 等价物，本修复是这些平台上唯一可用的缓解路径，验收需覆盖无 MPS 环境。

参考

• Work: HOST_BRIDGE CUDA 载体吞吐归因收口——环境级 MPS 观测缺口、旋钮合并与 action 路径根本修复 #2479（归因与新基线数据）、Roadmap: 收敛推理 transport 为单一 CUDA ring 路径，消除 CPU slot NumPy 接缝 #2365、Work: mujoco CUDA-carrier 默认拓扑 SAC apply_action 回退归因与 CUDA MPS 启用 #2366
• src/unilab/managers/action_manager.py、src/unilab/rl/runtime/collector_timing.py（apply_action 计时来源）