新增 gfx1151（Strix Halo）ROCm 镜像、构建期补丁与 nightly 发布流水线
值得精读，但读者按角色区分：负责 ROCm/发布基础设施的工程师应逐行看 docker/patches/sgl-kernel-gfx1151.sh，它是本 PR 信息密度最高的部分——wave32 部件上 host/device 两遍编译 WARP_SIZE 不一致会引发 `hipErrorLaunchFailure` 并把报错“甩锅”给后续 kernel，这个排障经验可迁移到其他非 gfx9 目标；同时“先 grep 断言原文、再就地替换、上游改动即 build fail”的构建期打补丁模式，对任何需要在固定上游源码上做临时适配的场景都值得借鉴。只做模型侧开发的读者可略读。需要重点盯的两个设计决策：一是 AITER“装但不用”（`SGLANG_USE_AITER=0` + 不设 PREBUILD_KERNELS）这一妥协，其代价是 Triton 被换成 3.7.0，目前无 CI 验证；二是把 gfx1151 支持完全寄托于镜像构建期补丁而非源码，删除条件已写进 PR body（PR#31137），建议在后续 PR 合并时同步清理并与 PR#31403 一起收口。
退役 CUDA 12 构建发布通道，为 PyTorch 2.14 铺路
值得精读，尤其对负责发布流水线、镜像与依赖管理的工程师：这是一次「删除为主」的 PR，真正的决策密度集中在少数几处。建议重点关注三点：一是 `scripts/update_kernel_whl_index.py` 把 CUDA 版本白名单替换为 `+cuNNN` 正则匹配——这是 fail-closed 的稳健性提升，杜绝了未来新 CUDA 版本的 wheel 误入 cu130 索引，值得作为同类脚本的范式；二是 `_docker-build-and-publish.yml` 中 manifest 固定使用 cu130 digest 后 `tag_config.cuda` 字段被静默忽略，建议合并后排查所有调用方并显式拒绝（或警告）非 cu130 的 `cuda` 取值；三是给 `check_wheel_cuda_version` 补一组针对 `+cu129` / `+cu130` / 无标记 / `+rocm720` 的单测。对 CUDA 12 用户，应在 release notes 中明确「v0.5.19 为最后一个 CUDA 12 版本」以及升级到 CUDA 13 的路径，避免他们从新的报错提示里得不到有效指引。
