opencl: use Adreno trans-weight GEMM for narrow q4_0 weights (a7x) - #30646

Overview

use_adreno_kernels() gates the Adreno trans-weight GEMM path behind
ne0 >= 512 && ne1 >= 512 for E031 >= 38.11 compilers (older compilers use
128). As a result, every q4_0 weight with ne1 < 512 falls back to
kernel_mul_mm_q4_0_f32_l4_lm, which on Adreno 740 runs at ~5-11 GFLOPS
while the trans-weight GEMM reaches ~300-500 GFLOPS on the same shapes —
~50x slower.

The affected weights are exactly the narrow ones: K/V projections
(ne1 = kv_dim), per-layer embedding gates/projections (ne1 = n_embd_altup),
and low-rank adapters (ne1 = rank). On gemma-4-E2B these run once per layer,
and kernel profiling shows the l4_lm kernel accounts for 79 % of the
prefill time (-DGGML_OPENCL_PROFILING=ON: 4.4 s of 5.6 s per 256-token
batch; 92 calls x ~48 ms).

This PR lowers the threshold to 128 — the value the same function already
uses for older compilers. The shape constraints for the transposed layout
(ne0 % 32 == 0, ne1 % 4 == 0, ne2 == ne3 == 1, element count < 2^27) are
still enforced by enable_adreno_trans_weight().

Additional information

Verified on Adreno 740 (E031.41.03.64), llama-bench --device GPUOpenCL -ngl -1 -p 256 -n 64 -r 2:

Greedy 24-token generation is byte-identical between the two builds.

Evidence: GGML_SCHED_DEBUG=2 shows only the q4_0 embedding gathers on CPU;
the per-kernel profile (cl_profiling.csv) attributes 4.4 s of 5.6 s to
kernel_mul_mm_q4_0_f32_l4_lm at ~10.8 ms per small matmul.

Alternative fix: repair kernel_mul_mm_q4_0_f32_l4_lm itself (it is ~1000x
slower than a straightforward tiled-GEMM estimate); this PR takes the
low-risk route of using the already-fast path.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES — the analysis, fix and on-device verification were
  developed with AI assistance (opencode). I understand the change fully and
  will maintain it.