issue #2 diagnostic: v0.6 fork commits without the upstream rebase

Diagnostic build for #2, not part of the v0.x line and not benchmark-validated.

This is v0.6's fork content without the upstream rebase: b7b85da (the build reported
as fast) plus only the four Vulkan commits that came after it, cherry-picked clean, with
the upstream merge 7a57bed left out entirely.

• 3980a48 vulkan: four env-gated Strix Halo prefill fixes for delta-net MoE
• 30296fa vulkan: reject ne[3] > 1 in the mul_mat_id scale epilogue
• 0525bfc vulkan: create coopmat2 mul_mat_id pipelines with the real param count
• d33bd12 vulkan: scale the FA MMQ dot product in fp32 before narrowing

76ad2ba is intentionally absent. It patches upstream #22789's growable split inputs,
which do not exist at b7b85da, and that base already cuts on the constant, so its
behaviour is already present.

What it is for

If v0.6 is slower than b7b85da on your box, this build separates the two possible causes:

• no-rebase is fast, v0.6 is slow -> the regression arrived with the upstream merge,
  and I will bisect that range.
• both are slow -> it is one of my four commits.
• both are fast -> it is not the llama.cpp source at all.

Toolchain note, please read before comparing

This build uses gcc 13.3.0, the same compiler as the v0.6 payload, which was hand-cut
on-box. So no-rebase vs v0.6 is a clean same-toolchain comparison, and that is the
pairing that answers the question. The b7b85da payload was an automated CI build with
gcc 14.2.0, so that pairing carries a compiler difference. Measured here, that difference
is worth about 7.5% on CPU-backend prefill in gcc-13's favour and nothing on GPU work,
so it does not explain a v0.6 slowdown, but it is worth knowing it exists.

Driver is unchanged from v0.6: Mesa 26.3.0-devel RADV (git-d18d598e), libdrm 2.4.133.

Status of the investigation

I could not reproduce the reported regression on my 64 GB box across seven configurations,
including speculative decoding at 34k context and a forced CPU/GPU split that exercises
the scheduler code from #22789. One thing is already ruled out: on DeepSeek-V4-Flash with
the DSpark drafter, graphs reused = 0 on both builds, so lost graph reuse is not the
mechanism.