Add Linux ROCm and Vulkan legs to the prebuilt pipeline, so AMD hosts stop landing on the CPU build

[LeoBorcherding]

Studio's MiniMax-H3 GGUF path asks this mirror for an sd-cli built for rocm. The latest release has none: macOS, Linux CPU, Linux CUDA, Linux aarch64, Windows CPU. So the installer falls back to leejet's upstream ROCm build, which doesn't carry the H3 fixes in this repo, and when that binary doesn't list a GPU, video.py drops to the CPU build.

That's unslothai/unsloth#8814:

Minimax H3 won't run on AMD card using Linux

7900 XTX on CachyOS, H3 goes installed to load_failed within a second. A Discord report this week on the same card and distro is the other shape of it: H3 Q3_K fills 30 GB of RAM and 36 GB of swap while VRAM sits at 1.5 GB.

What this adds

Three legs in unsloth-sd-prebuilt.yml, same rule as the CUDA leg: continue-on-error, not in the coverage gate, so they can never hold back the CPU and Apple assets.

leg	runner	asset
build-linux-vulkan	ubuntu-22.04	Linux-Ubuntu-22.04-x86_64-vulkan
build-linux-rocm	ubuntu-24.04	Linux-Ubuntu-24.04-x86_64-rocm-7.14.0
build-windows-vulkan	windows-2022	win-vulkan-x64, signed like the CPU leg

The ROCm leg builds against TheRock wheels like upstream's build.yml, but ships the ROCm userspace it linked against in the bundle: every library ldd resolves from the wheel tree, plus rocblas/library, rpath $ORIGIN, and it fails if anything is still unresolved with the wheel tree hidden. Upstream's zip doesn't do that, so it only runs on a host with a matching ROCm, which is the #8814 failure. Same shape as the ROCm leg in unslothai/llama.cpp.

package_bundle.py keeps rocblas/library (and hipblaslt/library) with their layout, since rocBLAS loads its kernels from next to librocblas. Everything else still lands flat.

Asset names are what Studio's resolve_release_asset already matches for rocm and vulkan, so a ROCm host picks these up with no Studio change. Not here: Windows ROCm, and the Studio-side fallback from rocm to vulkan before cpu (separate PR in unslothai/unsloth).

Test matrix

This workflow only runs on schedule and workflow_dispatch, so nothing on this PR exercises it.

what	ran	result
YAML parses, the three jobs are in assemble.needs, each continue-on-error	locally	ok
package_bundle.py on a fake bin tree: sd-cli, nested sd-server, libamdhip64.so.7, rocblas/library/*.dat, a stray notes.txt	locally	kernel tree kept with its path, libs flat, stray file dropped
the three legs on GitHub runners	no	needs a workflow_dispatch with publish: false, keep_artifacts: true
the ROCm bundle on an AMD Linux box	no	the ldd gate in the leg is the only proof it stands alone
the Vulkan bundles on any AMD box	no

Solid: packaging and workflow shape. Not proven: that any leg builds, or that the ROCm bundle runs H3 on a real card.