openkal measurement: the pinned graph declares [c-abi] for the first time

tests/openkal/pins.toml moved `runtime` from 0.10.0 to 0.12.0. Below that
version no package the pin resolves declares a `[c-abi]` block, so mcpp
realises nothing for the target side and the Windows leg compiles as
x86_64-w64-windows-gnu with `_WIN32` defined --- the condition every
`#ifdef _WIN32` branch in the measured members selects on. Every Windows
result recorded under 0.10.0 therefore measures the behaviour the
declaration exists to replace rather than the declaration.

The descriptors for both packages were already registered (#441, #442) and
their two mirrors compared byte for byte before this move: openkal-musl
0.16.0 and openkal-llvm-runtime 0.12.0 each answer the same sha256 from the
GitHub archive and the GitCode asset.

Co-authored-by: Claude Code <noreply@anthropic.com>

Author: Sunrisepeak

tests/openkal/pins.toml

@@ -4,7 +4,7 @@
 # `runtime` is the C++ runtime for openkal; it pins openkal-musl exactly, and
 # openkal-musl selects the openkal implementation for each target, so this one
 # version names the whole graph.
-runtime   = "0.10.0"
+runtime   = "0.12.0"
 toolchain = "llvm@22.1.8"
 # `mcpp` here moves together with index.toml's `min_mcpp` and
 # .github/workflows/openkal-compat.yml's own MCPP_VERSION (that workflow
@@ -18,15 +18,21 @@ toolchain = "llvm@22.1.8"
 # index requires mcpp >= 2026.9.18.1 but this is mcpp 2026.9.17.3 [E0006]"
 # before a single line of the member's own source is read.
 #
-# `runtime` does NOT move here: openkal-llvm-runtime 0.11.0 (the version that
-# actually declares/consumes `[c-abi]`) is not published yet -- see the note
-# in pkgs/o/openkal-llvm-runtime.lua. Bumping `mcpp` alone, ahead of it,
-# changes nothing observable today: no package this pin resolves declares
-# `[c-abi]`. Verified locally (not merely asserted): a full run of every
-# member listed below against x86_64-linux-gnu, under 2026.9.18.1, reproduces
-# the checked-in baseline exactly -- same 27 runs / 3 fails, same three
-# members (expat, curl, cmp-module), same diagnostics character-for-character
-# past the local path prefix.
+# `runtime` MOVES HERE NOW, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH
+# WITH NO `[c-abi]` IN IT. openkal-llvm-runtime 0.12.0 (openkal-musl 0.16.0,
+# openkal 0.14.0) is the first pinned graph in which a package declares the
+# block, so it is the first in which mcpp realises `presents = "posix"` at all:
+# below it the Windows target compiles as `x86_64-w64-windows-gnu` with `_WIN32`
+# defined, which is the condition every `#ifdef _WIN32` branch in the measured
+# members selects on. A result taken under 0.10.0 therefore says nothing about
+# the declaration -- it measures the behaviour the declaration exists to
+# replace. mcpp-community/mcpp#674 was opened against results of that shape.
+#
+# The two mirrors of both packages were compared byte for byte before this
+# move (GLOBAL archive against the GitCode asset, sha256 equal for
+# openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0), because a pin that
+# moves onto an unreachable or divergent asset fails every member at once and
+# reports it as a compatibility result.
 mcpp      = "2026.9.18.3"
 
 targets = ["x86_64-linux-gnu", "x86_64-windows-gnu"]