ggml-metal : exclude STQ1_0 from Metal mul_mat supports_op

[Sube-py]

Overview

Fix a hard crash when loading an STQ1_0 GGUF model on Metal with -ngl > 0.

ggml_metal_supports_mul_mat_op only excludes GGML_TYPE_NVFP4, so GGML_TYPE_STQ1_0 (added by #22836; CPU/ARM-NEON only, no Metal kernel) passes the check. The scheduler then places STQ1_0 weights in Metal buffers, and at compute time the kernel_mul_mv_stq1_0_* pipeline does not exist - the lookup path aborts with Asserting on type 43 / crashes with EXC_BAD_ACCESS in ggml_metal_encoder_set_pipeline.

This PR adds STQ1_0 to the exclusion, the same pattern #19769 used for NVFP4. It also reserves the GGML_TYPE_STQ1_0 enum id (43) to match the value used by #22836, so the two PRs compose cleanly regardless of merge order. On this base (9723942) the type id does not exist yet, hence the 2-line enum addition.

Note: with this fix, -ngl > 0 on an STQ1_0 model works but is much slower than -ngl 0 (Apple M3: tg64 ~22 t/s vs ~80 t/s) since every STQ matmul crosses the CPU/GPU boundary. Users should still prefer -ngl 0 until a Metal kernel exists. The fix only removes the hard crash / abort.

Additional information

Reproduced on Apple M3, macOS 26.5: llama-bench -ngl 99 and llama-server -ngl 5 both crash before the fix; both run after it (STQ1_0 tensors stay on the CPU backend, the rest of the graph still offloads).

Regarding the "multiple backends" note: this PR touches only ggml.h (type id reservation) and Metal. No CPU/CUDA/Vulkan code is modified - the one-line Metal change exists because that is where the crash originates.

Tests:

• llama-bench -ngl 99, llama-server -ngl 5, llama-completion -ngl 99 with Hy-MT2-1.8B-1.25bit: crash before, run after (Apple M3)
• ./build/bin/test-backend-ops test -b metal: passes after the change (3/3 backends OK)
• Translation output with the Hy-MT2-1.8B-1.25bit model unchanged vs -ngl 0

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES - AI was used to locate the crash cause in the Metal backend and to draft this description. The author understands and takes full responsibility for every line of the change (a one-line supports_op exclusion, same pattern as ggml : add NVFP4 quantization type support #19769).

[ggml-gh-bot]

Hi @Sube-py, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

• PR Template not respected: Please respect the template when creating a new pull request. Make sure to fill out all required sections.

• Multiple backend changes in one PR: When adding support for a new model or feature, focus on CPU support only in the initial PR. Add support for other backends like CUDA in follow-up PRs. If you have a good reason to modify multiple backends in one PR, please explain it.

---

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.