feat: 将 cuda/rocm torch 档位下放到可安装的 workspace 成员包，避免 git 依赖消费方重复配置

[wlgys8]

背景

当前 GPU 轮子档位（cuda/rocm）的 extras 与 torch 的 index 路由都定义在根项目 motrix-lab 的 pyproject.toml 中，包括：

• [project.optional-dependencies] 里的 cuda（torch==2.7.0 + cu128 index）与 rocm（torch==2.11.0 + rocm7.2 index + triton-rocm + amdsmi）
• [[tool.uv.index]]（pytorch-cu128 / pytorch-rocm72，explicit）
• [tool.uv.sources] 中按 extra 门控的 torch/torchvision/torchaudio/triton-rocm 路由
• [tool.uv] conflicts（cuda/rocm 互斥）

而根项目是 package = false 的纯 workspace 容器，不可安装。成员包（如 motrix-rl）中的 torch 是刻意「裸」声明的（torch>=2.7,<3，不钉版本、不指定 index），注释写明版本与 index 由根项目的 extras 决定。

问题

通过 git 依赖消费成员包的外部项目（tool.uv.sources 指向 git+https://github.com/Motphys/MotrixLab#subdirectory=motrix_rl）：

1. 无法触达根项目的 extras——它不在依赖图里；
2. 想要确定性的 GPU 档位（钉版本 + 指定 pytorch index），只能在消费方项目里完整重抄上述 extras + index + sources（约 40 行），形成两份需要人工保持同步的事实来源，上游调整 torch 版本时消费方会静默漂移。

依据（已实验验证）

uv 对以 git/源码形式构建的依赖会读取其 pyproject 并应用其自身的 [tool.uv.sources]、[[tool.uv.index]] 与 extras（已发布 wheel 的元数据则不携带 sources，不适用）。对照实验：一个在自身 pyproject 中声明了 torch→cu128 路由与 cuda extra 的合成库，经 git 依赖被消费时——

• 消费方写 lib[cuda]：torch 解析为 2.7.0+cu128（库的钉版与 index 路由全部生效）；
• 消费方写 lib（无 extra，sources 按 extra 门控时）：torch 仍从默认 index 解析，默认行为不变。

建议

1. 将 cuda/rocm extras、两个 pytorch index、按 extra 门控的 sources 与 conflicts 下放到 motrix-rl（或专职成员包）的 pyproject.toml；
2. 根项目的 extras 改为引用成员 extras：cuda = ["motrix-rl[cuda]"]、rocm = ["motrix-rl[rocm]"]——仓库内 install.sh 工作流不变，同时消除第二份钉版；
3. sources 条目保持按 extra 门控（同现状根项目写法），确保不带 extra 的默认解析路径（PyPI）不受影响。

消费方收益：从重抄约 40 行配置变为两行：

[project.optional-dependencies]
cuda = ["motrix-rl[cuda]"]
rocm = ["motrix-rl[rocm]"]

备注

• PyPI 上 torch 名下没有 ROCm 轮子，因此 ROCm 档位无论如何都需要一个显式开关；本方案已达到「消费方零版本钉死、零 index 配置」的下限。
• 更进一步的选项（与本方案不冲突）：将成员包 wheel 发布到 pypi.motphys.com，并可镜像 rocm 轮子，使 rocm 档位完全自解析；代价是失去「钉 commit 跟源码」的消费方式，适合作为稳定版通道与 git 依赖并存。