…e GGUFs load (#14565)

## Summary

Moves Studio's pinned stable-diffusion.cpp prebuilt from
`master-968-8cd731e-ubdb47d1` to `master-982-0518b34-ud331c66`, the
build published today from unslothai/stable-diffusion.cpp#34. master-968
predates MOSS-Image (upstream master-975, which also brought split-QKV
GGUF loading), so a MOSS-Image GGUF cannot load on the current pin;
every other family keeps working on the new base.

## What it does

- `studio/install_sd_cpp_prebuilt.py`: `DEFAULT_TAG =
"master-982-0518b34-ud331c66"`, with the comment explaining why
master-968 is no longer enough. `UNSLOTH_SD_CPP_TAG` still overrides,
and a missing tag still falls back to latest.
- Tests that name the pinned bundle and its asset names
(`test_sd_cpp_args.py`, `test_sd_cpp_vulkan_cpu_torch.py`,
`test_diffusion_more_families.py`, `test_sd_cpp_install.py`) move to the
new tag; the previous pin stays in the accepted-tags list.

## Checks

- The release carries the same 13 assets as master-968 (Linux x86_64 CPU
/ Vulkan / CUDA 12 / CUDA 13, Linux aarch64, Windows CPU / Vulkan / CUDA
12 / CUDA 13, macOS arm64 / x86_64, manifest, sha256 list), so no
platform loses its bundle.
- `UNSLOTH_BUILD.txt` in the Linux CUDA 12 bundle names source commit
`d331c66caa` and the MOSS-Image architecture marker is present in both
`sd-cli` and `sd-server`.
- Installed through `install_sd_cpp_prebuilt.py --accelerator cuda
--cuda-major 12` into a scratch directory, then rendered a
MOSS-Image-SFT UD-Q4_K_XL GGUF through Studio's own
`SdCppDiffusionBackend` (server mode, 512x512, 20 steps, CFG 3) on a
B200: the router picked sd.cpp, the model loaded and the render came out
clean (a fox in snow with the prompted sign text).
- Old pin vs new pin, same host, same Studio code, Studio's own
`SdCppDiffusionBackend` in server mode, 512x512, seed 42, each arm in
its own process (the running `sd-server` binary checked per arm):

| Family (Q4_K_M GGUF) | Steps | Old vs new pixels |
|---|---|---|
| Z-Image-Turbo | 8 | bit-identical |
| FLUX.2-klein-4B | 4 | bit-identical |
| FLUX.1-schnell | 4 | bit-identical |
| Qwen-Image | 20 | bit-identical |
| Qwen-Image-2.1 | 20 | bit-identical |
| FLUX.3 Image Klein | 4 | bit-identical |

Old vs old and two renders in one process were also bit-identical, so
the comparison could have caught any change. Load time and peak VRAM
matched within noise (the arms shared cards, so no speed claim).
- Tests: `test_sd_cpp_install.py`, `test_diffusion_more_families.py`,
`test_sd_cpp_args.py`, `test_sd_cpp_vulkan_cpu_torch.py`: 411 passed, 1
skipped.

## Not verified

- Only the Linux CUDA 12 bundle was installed and run here; the Windows,
macOS, Vulkan and aarch64 bundles are checked by asset name only
(staging covers the install path on Windows and macOS).
- Paths the 14 upstream commits between the two bases touch beyond
MOSS-Image were not rendered: LoRA (the `--lora-apply-mode auto`
heuristic for quantized weights), edit / img2img, Qwen-Image-Edit and
Layered, MiniMax-H3 video, and the CUDA 13 / Vulkan / ROCm / CPU / macOS
/ Windows bundles.
- The Windows and macOS staging legs fail three tests this PR does not
change (`test_sd_cpp_args.py::test_native_speed_flags`,
`::test_minimax_h3_video_command_has_all_joint_av_components`,
`test_sd_cpp_install.py::test_safe_extractall_installs_a_chain_the_loader_can_still_walk`
on macOS;
`test_sd_cpp_install.py::test_a_failure_finalising_the_new_tree_is_an_incomplete_replacement`
on Windows). Only the pinned tag strings change in those files, and
these tests run on those runners only when a PR touches them, so they
fail the same way on main.