Add/Improve the test coverage for NativeVectorUtilSupport

### Description

Currently, NativeVectorUtilSupport is only exercised in tests when the user explicitly enables it and provides a native binary with overridden implementations. Even then, not all code paths and VectorUtil
operations are covered but only the ones overridden in the provided binary (e.g., the issue @ExE-Boss found [here](https://github.com/apache/lucene/pull/15508#discussion_r2960053681)). The native path is not tested automatically in our CI workflow which disconnects it from other implementations.

One option is to generate a simple native binary purely for test coverage - not architecture-specific optimized code, just trivial C implementations that exercise the FFM calling convention and code paths. This
would keep maintenance overhead low since the binary wouldn't need per-arch tuning and only supposed to be used for testing(and also provide as base for users to build on if they want to write more optimized c code). Or we could just have fake java methods calling DefaultVectorUtil and use those to test the native path? That being said, there may be better approaches and I'm looking for suggestions and ideas to improve coverage here.

Start by locating NativeVectorUtilSupport and the existing tests that enable it with an overridden native binary, then inspect which VectorUtil operations and code paths remain uncovered. Compare the proposed trivial C binary and fake Java method approaches with the current FFM setup. Done means native-path coverage runs automatically in CI across the relevant operations and implementations.

Written by the indexing model from the issue text.