feat: 允许 ManagerApi 的 CommandTerm 与键盘/手柄等 InputDevice 做 binding

[wlgys8]

背景

Manager API（motrix_env_core/numba/manager/）中，命令由 CommandTerm / CommandCfg 在 fused kernel 内部生成（如随机采样、motion clip 对齐），没有从外部设备注入命令的标准入口。

与此同时，motrix_env_core/input/ 已经定义了一套输入抽象：

• InputDevice 层级：KeyboardDevice、GamePadDevice（input/device.py）
• CommandBinding 及实现：KeyboardPlanarVelocityBinding、GamePadPlanarVelocityBinding、BoundedGamePadPlanarVelocityBinding、ConstantPlanarVelocityBinding（input/bindings.py），统一通过 read_command(batch_size=...) 产出 PlanarVelocityCommand

但这两套体系目前没有打通：CommandBinding 只被旧的非 manager pipeline（walk_np.py）直接调用，Manager API 的 CommandTerm 无法消费设备输入。

动机

• 想用键盘 / 手柄 teleop 驱动一个 manager-based 任务时，缺少标准接入点，只能各写各的 ad-hoc 胶水代码
• 训练（随机采样命令）与部署 / teleop（设备驱动命令）走的是两套命令来源代码路径，行为容易不一致
• InputDevice / CommandBinding 抽象已经存在且质量不错，Manager API 侧应直接复用，而不是绕过它

提议

1. 在 Manager API 侧提供 device-driven 的命令接入方式，例如：
   • 一个通用的 device-driven CommandCfg / CommandTerm（或允许现有 CommandTerm 接受一个 CommandBinding 作为命令源）
   • host 侧在每个 step 统一 poll() 设备并 read_command(batch_size=num_envs)，把结果写入 kernel 的 command buffer
2. binding 与具体设备解耦：任何 InputDevice 实现（键盘、手柄、以及未来的 spacemouse、脚本注入等）都能通过实现 CommandBinding 接入，Manager API 只依赖 CommandBinding 接口
3. 复用现有命令映射语义：command_lower/command_upper、deadzone、deadman_button、axis invert 等
4. 明确 batch 语义：teleop 场景下 batch 内所有 env 通常共享同一命令（repeat），保持该行为并考虑是否需要 per-env 可配置

Acceptance criteria

• 至少一个 manager-based 任务可以用键盘 / 手柄作为命令源运行（teleop/play 路径）
• CommandTerm 与具体设备类型解耦，新增设备只需实现 InputDevice + CommandBinding，不需要改 Manager API
• 训练（随机命令）与 teleop（设备命令）共用同一套 CommandTerm / 命令消费代码路径
• 单测覆盖：binding → command buffer 的写入、poll() 的调用时机、batch repeat 语义