pins move to mcpp 2026.9.21.2 and openkal-llvm-runtime 0.15.0

[Sunrisepeak]

THE TWO MOVE TOGETHER BECAUSE THE MEASUREMENT IS ABOUT WHAT THE PAIR DOES.

The engine withdraws __CYGWIN__. Four members of this suite --- archive
(xz), sqlite3, mimalloc, c-ares --- stopped at #include <windows.h> reached
through #if defined(_WIN32) || defined(__CYGWIN__), and upstream means "Win32
is available" by that name. THIS MEASUREMENT IS THE CRITERION FOR THAT
CHANGE: the windows.h group should reach zero, and nothing that ran before
should stop running.

runtime -> 0.15.0 is what keeps the withdrawal safe. It pins openkal-musl
0.19.0, and both read __MCPP_TARGET_WINDOWS__ in the INSTALLED headers that
size jmp_buf and unw_context_t, keeping || defined(__CYGWIN__) beside
it. Measured on the engine branch before it merged: against the PUBLISHED
0.13.0, an openkal program for x86_64-windows-gnu fails on libunwind's two
static_asserts. Registered and published first --- #453, #455, #456 ---
before this line moved.

0.15.0 also makes thread_local destructors run, which doctest and
spdlog stop on today with undefined symbol: __cxa_thread_atexit. Those two
are the other half of what this run should report.

openkal-compat.yml's MCPP_VERSION moves with pins.toml because that
workflow checks the two agree. latest_mcpp moves; min_mcpp DOES NOT ---
this release adds no manifest key, so no client loses the index.

---

This run is the criterion for the __CYGWIN__ withdrawal. Expected: the
windows.h group (archive/xz, sqlite3, mimalloc, c-ares) reaches zero, and
nothing that ran before stops running. doctest and spdlog should also
clear, since 0.15.0 makes thread_local destructors work.

Verified before this PR: the published 2026.9.21.2 binary, in a SubOS sandbox
on the CN mirror, fails=0 with nothing skipped on the six-section
verification --- against fails=3 for 2026.9.21.1 in the same sandbox.