#2944 Run the AVX-512 CPU expert kernels on Skylake-X (16-register, VBMI-free)

Beschreibung

Summary
Skylake-X Xeons (e.g. Xeon Gold 6148) have AVX-512 F/BW/DQ/VL/VNNI but no VBMI, so cpu_avx512_ok() correctly gates them to the AVX-2 kernels. This adds a Skylake-X class gate plus VBMI-free kernel variants so those CPUs run the AVX-512 expert path. Full AVX-512 CPUs (Ice Lake+, Zen 4+) keep cpu_avx512_ok() and their existing code paths are unchanged.
Changes
- expert.cpp: the Q2_0 2-bit unpacks (unpack_q2_0, unpack64_q2_0) replace VPMULTISHIFTQB with per-qword shift emulation (slli 14 / srli 2,6,10 / slli 10 / srli 4,8,12, OR, AND 3) — bit-exact, same codes, same order.
- expert_layout.cpp: new cpu_avx512_skx_ok() (F+BW+DQ+VL+VNNI, NOT VBMI) and cpu_avx512_kernel_ok() = cpu_avx512_ok() || cpu_avx512_skx_ok(). Note: the original gate reads VL from ECX1 and VNNI from ECX11 — VL is CPUID 7.0:EBX24; the bit positions are fixed in the new gate (left untouched in the VBMI path).
- native_expert.cpp + expert_layout.cpp: kernel dispatch sites (avx512, cpu512, nvfp4_512, iq3s_one, exact_one, q2_rows_any*, act_quant_any) use cpu_avx512_kernel_ok().
- CMakeLists.txt: kernel TUs compiled -march=skylake-avx512 -mavx512vnni -mf16c -mfma (GCC's skylake-avx512 does not imply VNNI; no VBMI is emitted).
Safety for existing CPUs
- cpu_avx512_skx_ok() returns false whenever cpu_avx512_ok() is true — no behavior change on VBMI-capable parts.
- The shift emulation is bit-exact against VPMULTISHIFTQB, so rounding/verify-window consistency is preserved everywhere.
- AVX2-only CPUs: gates evaluate identically (both gates false) → unchanged.
Testing (Xeon Gold 6148, RX 6700 XT, gfx1031)
- Parity: iq_avx2_parity, nvfp4_avx512_parity, qsa_parity, dequant_s2_parity, iq_multi_parity, s2_expert_grouped_parity — 0 failures.
- Server smoke + 2.4K-prompt/300-token decode: clean, no SIGILL.
- 3× full bench: stable; performance flat vs AVX2 on this DRAM-bound box (Skylake-X double-pumps 512-bit ops), as expected — the win is correctness/coverage, not speed.
Known limits
GCC still allocates zmm16–31 in some kernels (no flag caps allocation to 16 regs); empirically those paths were never executed in the full bench suite (zero SIGILL). A strict 16-reg kernel pass would make this airtight. Performance gain is CPU-dependent: compute-bound workloads benefit; memory-bandwidth-bound ones won't.