Link libatomic where 64-bit atomics are not native, fixing the piwheels build

[fpedd]

Problem

The piwheels build of the 1.0.0 sdist fails on Python 3.11 (Raspberry Pi OS Bookworm, 32-bit). Raspberry Pi OS compiles for armv6 by default, where the 8-byte std::atomic operations of the C++ core (the int64 atomics in supermalloc.cpp, clock.hpp, placement.cpp, collision.cpp) have no native instruction and become calls into libatomic: __atomic_load_8, __atomic_store_8, __atomic_fetch_add_8, __atomic_compare_exchange_8.

nanobind_add_module links without --no-undefined, so the .so links fine but cannot be loaded. The _cpp_stub target, which runs in ALL, imports the freshly built module to regenerate _cpp.pyi, so the build aborts right after linking with an undefined-symbol ImportError. The same defect would break any 32-bit ARM user at import time even if the wheel had been produced.

Reproduced by cross-compiling the sources with arm-linux-gnueabihf-g++ -marm -march=armv6+fp -mfpu=vfp -mfloat-abi=hard and loading the result under qemu:

dlopen failed: ./lib.so: undefined symbol: __atomic_compare_exchange_8

Fix

CMakeLists.txt probes whether a 64-bit atomic links natively (check_cxx_source_compiles) and links atomic into _cpp when it does not. Where libatomic is missing as well, the linker reports it.

Verification

Target	Probe result	libatomic.so.1 in NEEDED	dlopen under qemu
x86_64 (host)	native	no	n/a, unit tests pass
armv7-a cross	native	no	ok
armv6 cross (Raspberry Pi OS default)	libatomic	yes	ok

The 1.0.0 sdist also builds cleanly on x86_64 with the current nanobind 3.0.1 and scikit-build-core 1.0.3 in pip build isolation, ruling out the build backend versions as the cause.