Meson cross-compilation detection fails when host and target architecture matches but differs by CPU flags

**Describe the bug**
We currently have an platform embedded platform that is x86_64 based for which we need to target the Alderlake tuning settings. And we are compiling the code from another x86_64 machine that does not support this CPU setting.

As such we have a toolchain.cmake for passing the cross-compilation settings according to CMake prescriptions as below.

```
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

set(CMAKE_SYSROOT /path/to/x86_64-buildroot-linux-gnu/sysroot)
set(CMAKE_C_COMPILER /path/to/x86_64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER /path/to/x86_64-linux-gnu-g++)

set(ENV{PKG_CONFIG_SYSROOT_DIR} "${CMAKE_SYSROOT}")
set(ENV{PKG_CONFIG_PATH} "${CMAKE_SYSROOT}/usr/lib/pkgconfig:${CMAKE_SYSROOT}/usr/share/pkgconfig")

set(CMAKE_C_FLAGS_INIT "-g -fPIC -mtune=alderlake")
set(CMAKE_CXX_FLAGS_INIT "-g -fPIC -mtune=alderlake")
```
When compiling something that uses the meson build system (e.g. libsystemd) the builds fails because cross-compilation is not detected properly though the presence of the toolchain (both machines are x86_64).

Hence it ends up failing as for https://github.com/microsoft/vcpkg/issues/11230 (see failure logs below)

**Environment**
- OS: Linux
- Compiler: GCC 14.3.1 20250818

**To Reproduce**
1. Create a custom toolchain with the same architecture as your host but with optimization flags for specific CPUs.
2. Compile a port using meson (e.g. libsystemd) on a machine where the optimization flag is not supported

**Expected behavior**
As we are already passing a toolchain to vcpkg through VCPKG_CHAINLOAD_TOOLCHAIN_FILE I would expect it to tell properly meson that we are cross-compiling.

**Failure logs**
```
Sanity testing C compiler: /path/to/bin/x86_64-linux-gnu-gcc -g -fPIC -mtune=alderlake -g --sysroot=/path/to/x86_64-buildroot-linux-gnu/sysroot
Is cross compiler: False.
Sanity check compiler command line: /path/to/x86_64-linux-gnu-gcc -g -fPIC -mtune=alderlake -g --sysroot=/path/to/x86_64-buildroot-linux-gnu/sysroot sanitycheckc.c -o sanitycheckc.exe -g -fPIC -mtune=alderlake -g --sysroot=/path/to/x86_64-buildroot-linux-gnu/sysroot -I/tmp/co/build/vcpkg_installed/triplet-x64-linux/include -D_FILE_OFFSET_BITS=64 -L/tmp/co/build/vcpkg_installed/triplet-x64-linux/debug/lib
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----
Running test binary command: /tmp/co/vcpkg/buildtrees/libsystemd/triplet-x64-linux-dbg/meson-private/sanitycheckc.exe
-----------
Sanity check: `/tmp/co/vcpkg/buildtrees/libsystemd/triplet-x64-linux-dbg/meson-private/sanitycheckc.exe` -> 127
stderr:
/tmp/co/vcpkg/buildtrees/libsystemd/triplet-x64-linux-dbg/meson-private/sanitycheckc.exe: CPU ISA level is lower than required
```

So it clearly states : `Is cross compiler: False.` though we passed a custom toolchain.
And sanity check fails because the CPU settings are not supported so the executable cannot be run on the host.

**Additional context**
I understand that I might be possible to pass VCPKG_MESON_CROSS_FILE to my toolchain and specify myself parameters from there but it feels clumsy because

1. I'm not using meson directly, it's a dependency of my dependencies so I feel this should not be my responsibility to maintain a build system I'm not directly using
2. I'm already providing a toolchain to vcpkg and vcpkg already seems to try to address meson builds through vcpkg_configure_meson.cmake internally. It would be better to only have one source of truth.

Thanks for your help.

Start by tracing vcpkg_configure_meson.cmake and how it handles VCPKG_CHAINLOAD_TOOLCHAIN_FILE and VCPKG_MESON_CROSS_FILE. Reproduce with the toolchain.cmake example and a Meson-based port such as libsystemd; done means Meson recognizes cross-compilation and does not run the incompatible sanity-check executable.

Written by the indexing model from the issue text.