Fix ARMV9SME kernel selection in CMake cross builds

[Kiptoo-Deus]

Follow-up to #5978 (for #5976).

#5978 added ARMV9SME to the ARMV8SVE block in cmake/prebuild.cmake, but ARMV9SME is also listed earlier in the same if/elseif chain, in the NEOVERSEN2 block. That block is matched first, so ARMV9SME still gets SGEMM_UNROLL_N/DGEMM_UNROLL_N of 4. KERNEL.ARMV9SME includes KERNEL.ARMV8SVE, which uses the 2x8/1x8 SVE kernels, so the build looks for files like sgemm_kernel_sve_v2x4.S that don't exist.

This removes ARMV9SME from the NEOVERSEN2 block so it reaches the ARMV8SVE block as intended.

This only affects the CMake path that writes the config without running getarch, i.e. cross builds. Native builds get the values from getarch.

Tested on macOS (Apple M, AppleClang 21) by cross-configuring develop with -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_SYSTEM_PROCESSOR=arm64 -DTARGET=ARMV8 -DDYNAMIC_ARCH=ON -DNOFORTRAN=ON:

• before: fatal error: '.../kernel/arm64/sgemm_kernel_sve_v2x4.S' file not found (and sgemm_kernel_inter_sve_v2x4.S)
• after: builds, the ARMV9SME kernels are in libopenblas.a, and ctest passes (14/14)

Unrelated, but I hit it while testing: with the Ninja generator on macOS, libopenblas.a on develop ends up containing only xerbla.c.o. In CMakeLists.txt the Ninja-specific CREATE_STATIC_LIBRARY_COMMAND is set and then overwritten right after the if/else by the objects*.rsp version, which Ninja doesn't generate. I used the Makefiles generator for the test above. Happy to open a separate PR for that if useful.