feat(toolchain,build): llvm-musl static target — target libc++ payload axis

[yspbwx2010]

Summary

• The LLVM family could not serve *-linux-musl: a clang frontend carries no target libc, and the hosted clang-with-cfg path reconstructs the HOST's world (glibc payload, host libc++), which is exactly wrong for the target.
• triple: new TargetInfo::llvmSysroot column + effective_llvm_sysroot(). The gcc-musl payload path is untouched (self-contained); the column names an xim package carrying the target's musl libc++ for the LLVM family only.
• prepare: clang-on-musl resolves that payload into targetSysroot* and points stdModuleSource at the payload's std.cppm, so the std BMI is built over the target's libc++, not the host's.
• flags: isLlvmMusl branch for compile and link — neutral driver (--no-default-config), target triple, --gcc-toolchain to the musl-gcc payload for crt/libgcc/libc, -nostdinc++/-nostdlib++ with explicit musl libc++ archives; the host kLinkDriverFlags (compiler-rt/libunwind) do not appear.

The payload package (xim:llvm-musl-libcxx) ships separately in the package index; until it exists this branch simply does not arm — zero behavior change for every existing toolchain/target combination.

Design doc: .agents/docs/2026-08-23-llvm-musl-target-design.md (in this PR).

Background: the gcc-musl route is currently blocked by a GCC 16 modules ICE (BMI read-back segfault; the gdb register dump shows a corrupted in-heap tree pointer inside cc1plus), while clang 22 compiles the same module-heavy codebase cleanly. This PR is the engine half of the llvm-musl route; the payload half follows in the package index.

Closes #491

Test plan

• mcpp test unit/integration: 91 passed; 1 failure in unit/test_elf_runtime that is environmental and pre-existing on this sandbox (host /lib64/libtinfo.so.6 is a symlink chain, weakly_canonical rewrites the name the assertion greps for — unrelated code path, 3/3 reproducible with the change stashed)
• New effective_llvm_sysroot tests: test_toolchain_triple 28/28 (3 new)
• Self-hosted build green with the change (release, 125s incremental)
• End-to-end: mcpp build --toolchain llvm@22.1.8 --target x86_64-linux-musl on a module-heavy workspace (~240 module TUs) once the payload package lands — validated locally via an equivalent direct-clang pipeline producing fully static x86_64 and aarch64 (qemu-verified) binaries

[yspbwx2010]

End-to-end verification complete — the first push had four defects that only a real build against the payload exposed (all fixed in 728c2c5):

1. The vocabulary pin silently replaced --toolchain (the env side channel it arrives through was invisible to the pin guard), so --toolchain llvm@22.1.8 --target x86_64-linux-musl resolved gcc@16.1.0.
2. The target-triple correction was freestanding-only; llvm-on-musl is the same one-binary case, so the output dir / cache key / flags all stayed on the host triple.
3. The std BMI was built over the host libc++ headers and glibc (__config_site / bits/alltypes.h not found); it now uses the payload's headers over the musl-gcc sysroot.
4. The clangWithCfg PayloadFirst link flags leaked the host glibc loader into a static binary's PT_INTERP (runtime segfault).

Verified: mcpp build --toolchain llvm@22.1.8 --target x86_64-linux-musl on a module project now yields a fully static x86_64 musl ELF (no PT_INTERP, not a dynamic executable) that runs. Unit suite 91 passed; the single test_elf_runtime failure is the known environmental one (host /lib64/libtinfo.so.6 symlink chain), reproducible with the change stashed.