[bsergean]

Some 32-bit toolchains emit runtime calls for the library's 64-bit atomic counters. Building a static archive succeeds, but applications linking it fail with unresolved symbols such as __atomic_fetch_add_8.

Probe a C++11 64-bit atomic fetch-add and load with an executable link. If the compiler cannot link it directly, retry with libatomic and attach that dependency to the library. Fail configuration with an actionable message if neither works. Keep the check scoped so it also works with cross toolchains that normally use static-library compile probes.

Carry the dependency through the exported static CMake target and pkg-config --static metadata. Platforms whose toolchains already support the operations receive no extra library. Counter widths and runtime behavior are unchanged.

Add a simple Linux 32-bit CI job and make -f makefile.dev test_atomic_32. GCC's -m32 -march=i486 forces the atomic runtime path; the check installs the library, then links and runs C++11 consumers using both CMake and pkg-config. The producer deliberately uses compile-only default probes to verify that atomic detection still checks the linker.

Validation:

• Reproduced the original __atomic_fetch_add_8 linker failure with GCC 12 targeting 32-bit i486.
• With the fix, installed static CMake/pkg-config consumers and a shared-library consumer link and run under qemu-i386.
• Native macOS static consumers pass through CMake and pkg-config without libatomic.
• All 24 native macOS test suites pass; strict C++11 and deprecated API checks pass.
• Workflow YAML, formatting, and git diff --check pass.
• All nine GitHub CI checks pass, including the new Linux 32-bit installed-consumer check, Linux/ASAN, macOS TLS backends, Windows GCC, and UWP.

The historical 32-bit macOS toolchain from the report was not available locally; the check is based on compiler/linker capability rather than an OS or architecture list.

Closes #513.