-latomic has no answer in the openkal graph on linux-musl targets #31

Measured by mcpplibs/mcpp-index#469 (the openkal measurement, mcpp 2026.9.26.1, openkal-llvm-runtime 0.15.2, openkal-musl 0.19.2), on the two linux-musl rows it added:

x86_64-linux-musl   mimalloc  fails: ld.lld: error: unable to find library -latomic
aarch64-linux-musl  mimalloc  fails: ld.lld: error: unable to find library -latomic

compat.mimalloc links -lpthread -lrt -latomic on Linux (its CMakeLists.txt:618-626). From mcpp 2026.9.26.1 a link over a graph-supplied C library searches no host library directory (mcpp-community/mcpp#696): -lpthread and -lrt are answered by the empty archives openkal-musl 0.19.2 ships, and -latomic is answered by nothing. Before that release the host's libatomic (a glibc-world library) answered it, silently.

libatomic is the compiler runtime's library, not the C library's, so the name belongs to this package. Two candidate answers, and the choice needs a measurement rather than a guess:

1. If the compiler-rt builtins this package builds include the __atomic_* library fallbacks (compiler-rt/lib/builtins/atomic.c), ship an empty libatomic.a and a package-relative -L, exactly as openkal-musl does for musl's eight names: every symbol -latomic would supply is already on the link line.
2. If they do not, an empty archive would turn a clean refusal into an undefined __atomic_load_16 at link time for a program that needs them; the builtins would then have to gain atomic.c, and libatomic.a would carry it.

The criterion is the same program on both rows: mimalloc's tests run, and a 16-byte std::atomic load links and runs.