ggml-cpu: add Q1_0 AVX2 fast path

[elusznik]

ggml-cpu: add Q1_0 AVX2 path

Commit message

ggml-cpu: add Q1_0 AVX2 dot product

Add an AVX2 SIMD fast path for ggml_vec_dot_q1_0_q8_0() in the
CPU backend quants.c. The Q1_0 quantization format packs 32
weight bits per 32 bytes, which requires a bits-to-bytes expansion
step before the int8 dot product can run. This patch reuses the
existing helpers (bytes_from_bits_32, mul_sum_i8_pairs_float) to
keep the implementation minimal and consistent with the q4/q5
kernel style.

The scalar fallback remains intact for non-AVX2 builds.

PR title

ggml-cpu: add Q1_0 AVX2 fast path

PR body

## Summary

Adds an AVX2 SIMD implementation of `ggml_vec_dot_q1_0_q8_0()` to
`ggml/src/ggml-cpu/quants.c`. This is the core dot-product kernel
used during inference with Q1_0 quantized weights (1-bit models
like Bonsai).

## Motivation

Q1_0 currently falls back to a scalar loop on x86 targets because
there was no AVX2 kernel. For comparison, ARM NEON has a native
Q1_0 implementation. The scalar fallback is particularly slow for
Q1_0 because the inner loop decodes 32 packed bits per iteration.

## Changes

- `ggml/src/ggml-cpu/quants.c`: added three static inline AVX2
  helpers (`hsum_float_8`, `bytes_from_bits_32`,
  `mul_sum_i8_pairs_float`) and the AVX2 fast path for
  `ggml_vec_dot_q1_0_q8_0()`. Scalar fallback kept for non-AVX2
  builds.

## Benchmark

Micro-benchmark (`test-quantize-perf`, synthetic data, vec_dot_q):

| Size    | Baseline cycles/32 | AVX2 cycles/32 | Speedup |
|---------|-------------------:|---------------:|--------:|
| 4 KB    | 104.38             | 6.32           | ~16.5x  |
| 64 KB   | 103.62             | 5.56           | ~18.6x  |
| 2.5 MB  | 104.76             | 5.76           | ~18.2x  |
| 250 MB  | 105.56             | 5.98           | ~17.6x  |

End-to-end server inference (`llama-server`, Bonsai-8B Q1_0, 16
threads, ctx-size 512):

| Metric       | Baseline | AVX2    | Speedup |
|--------------|---------:|--------:|--------:|
| Prompt eval  | 1.24 t/s | 18.64   | ~15x    |
| Generation   | 1.13 t/s | 18.01   | ~16x    |

All llama-bench results on the modified build confirm no regressions
on other quantization formats.

## Testing

- `test-quantize-perf --type q1_0 --op vec_dot_q -4` on both builds
- `llama-bench` on Bonsai-8B Q1_0 (16 threads) shows no regressions
  for other quants
- `llama-server` inference on Bonsai-8B Q1_0 produces correct output

[gemini-code-assist]

Code Review

This extensive pull request introduces support for the Gemma 4 model architecture, including its per-layer embeddings and specialized chat templates. It implements the new Q1_0 quantization type and adds NVFP4 support for CUDA and SYCL backends. Significant performance enhancements are provided for the WebGPU backend through optimized shaders for MUL_MAT_ID and flash attention, while the CPU backend receives RISC-V vector optimizations. Other improvements include new CUMSUM support for Hexagon, Q4_K support for Adreno GPUs, and revised contribution guidelines for AI agents. Feedback suggests improving maintainability by refactoring repetitive requirement checks into a loop, breaking down complex parser logic, and consolidating duplicated FP8 conversion code. Additionally, the reviewer recommends using a dispatch table for device detection, vectorizing WebGPU output logic, and deriving hardcoded layer counts from existing parameters.

[gemini-code-assist]

This function is becoming quite large and repetitive. Consider refactoring to use a loop over an array of required binaries to improve maintainability.

[gemini-code-assist]

The function build_func_parser is quite complex. Consider breaking it down into smaller, more focused helper functions to improve readability and maintainability.

[gemini-code-assist]

The logic for converting FP8 to FP32 is duplicated across different architectures. Consider consolidating this into a single, robust implementation if possible to reduce maintenance overhead.

[gemini-code-assist]

The nested if statements for device architecture detection are becoming difficult to follow. Consider using a more structured approach, such as a dispatch table or a cleaner helper function, to improve readability.

[gemini-code-assist]

The output storage logic uses multiple if checks for bounds. Consider if this can be simplified or vectorized to improve performance and reduce code duplication.

[gemini-code-assist]

The switch-case for layer counts is hardcoded. Consider if this can be derived from other hparams or if a more flexible mapping is needed for future model variants.