fix: route avxvnni FMA ops through fma3<avx2> kernels (#1368)

batch<T, avxvnni> derived from avx2, so fnma/fnms fell back to the
generic neg(x*y)+z form (vxorpd + vfmadd) instead of the hardware
vfnmadd/vfnmsub kernels registered for fma3<avx2>. This bites
-march=native on Alder/Meteor Lake and Zen 5, where default_arch
resolves to avxvnni.

Derive avxvnni from fma3<avx2> instead. fma3<avx2> always derives from
avx2 and its kernels are guarded by XSIMD_WITH_FMA3_AVX2, so when FMA
is disabled the base is transparent and dispatch falls through to avx2
unchanged.

Validated under Intel SDE across avxvnni+FMA (-adl), fma3<avx2> (-hsw),
avx2-only (-hsw) and avxvnni-without-FMA (-adl): correct results, full
test_batch suite passes, vfnmadd emitted only where FMA is enabled.

Author: DiamonDinoia

include/xsimd/types/xsimd_avxvnni_register.hpp

@@ -13,6 +13,7 @@
 #define XSIMD_AVXVNNI_REGISTER_HPP
 
 #include "./xsimd_avx2_register.hpp"
+#include "./xsimd_fma3_avx2_register.hpp"
 
 namespace xsimd
 {
@@ -21,7 +22,12 @@ namespace xsimd
      *
      * AVXVNNI instructions
      */
-    struct avxvnni : avx2
+    // Derive from fma3<avx2> rather than avx2 so the FMA3 kernels (fnma/fnms ->
+    // vfnmadd) are in avxvnni's dispatch chain instead of the generic neg(x*y)+z
+    // fallback. fma3<avx2> always derives from avx2 and its kernels are only
+    // registered when XSIMD_WITH_FMA3_AVX2, so when FMA is disabled this base is
+    // transparent (dispatch falls straight through to avx2).
+    struct avxvnni : fma3<avx2>
     {
         static constexpr bool supported() noexcept { return XSIMD_WITH_AVXVNNI; }
         static constexpr bool available() noexcept { return true; }