tests: add BF16 non-contig coverage for MUL_MAT permutations

[ServeurpersoCom]

Overview

The MUL_MAT test loop iterates over base_types[] to generate non-contig permutation cases (3 standard permutations across n in {1, 8, 16}). BF16 is absent from base_types[], so these 9 cases were never generated for BF16 even though every other type covered by base_types[] tests them.

Add the missing 9 cases explicitly: BF16 x F32, m=16, k=256, bs=[2,3], permutations {0,2,1,3}, {0,1,3,2}, {0,3,2,1}, with n in {1, 8, 16}. All cases pass on Vulkan.

Verified independent of #22677: reverting that PR locally and rerunning the suite still shows 9 OK on these new cases, so the coverage exercises a path that was already correct (cpy bf16 -> bf16 materialization for non-contig matmul), distinct from the bf16 -> f32 cpy pipeline added in #22677.

This is a first pass. Other BF16 coverage gaps spotted while investigating, candidates for follow-up PRs:

• MUL_MAT_ID has only 2 BF16 cases vs around 75 for types in base_types (same structural gap as MUL_MAT)
• DUP has 0 BF16 cases at all
• ROPE supports_op returns true for any contiguous_rows tensor including BF16, but the dispatch only handles F32/F16/F32_F16, returning nullptr for BF16, potential latent abort similar to the cpy bf16 -> f32 case in vulkan: add cpy bf16 -> f32 pipelines #22677

Happy to attack each as separate PRs, or batch them depending on what you prefer.

Follow-up to #22677.
cc @jeffbolznv

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES Opus 4.7 + disposable rootless podman with CUDA/Vulkan GPU

[ServeurpersoCom]

Please 2nd approval @ggml-org/maintainers