openkal 0.13 and the packages that follow it; openkal compatibility labels - #437

…barchive under openkal; CI and the openkal measurement move to mcpp 2026.9.17.3 (#438)

* openkal-emscripten 0.2.0, std-freestanding-alloc-kal 0.1.6, and CI builds against mcpp 2026.9.17.3

The two packages resolve openkal 0.13.0 from this index, so their releases
follow #437. mcpp 2026.9.17.3 carries #662: a dependency graph that supplies the
C library is no longer mixed with the host's own headers. validate.yml and the
openkal compatibility measurement both move to it, and the measurement takes
openkal-llvm-runtime 0.10.0 (openkal-musl 0.14.0, openkal 0.13).

* compat.libarchive: macOS with musl builds without the Apple SDK (#434)

libarchive reads __APPLE__ as the Apple SDK being present (TargetConditionals.h,
copyfile, quarantine) in four private units and in the generated configuration;
in an openkal graph for macOS the SDK is not there. __APPLE__ is removed from
libarchive's own units under cfg(all(macos, c-abi = "musl")); archive.h and
archive_entry.h do not test it. Measured with mcpp 2026.9.17.3: the archive
member cross-builds for aarch64-macos above openkal-macos 0.10.0.

Windows with musl is not adapted, and the reason is recorded here rather than
worked around: libarchive writes wide string literals, which the Windows target
makes sixteen bits while musl's wchar_t is thirty-two, and openkal-musl refuses
that mixture on purpose (musl/PATCHES.md). The measurement reports it.

* compat.libarchive on Linux with musl, and the tinyhttps member at 0.3.1

The measurement against mcpp 2026.9.17.3 showed the archive member failing on
Linux above openkal: the Linux host configuration names linux/fs.h and its
neighbours, which belong to the kernel's interface and were reached only
because the compiler searched the host before mcpp#662. Under
cfg(all(linux, c-abi = "musl")) the generated configuration removes them as
it does on every other system; the member runs again.

The tinyhttps member names 0.3.1, which selects POSIX sockets on Windows with
musl; the measurement had been taken against 0.3.0.

* openkal-compat: a measurement requested on another branch proposes nothing

* compat.py: a measured copy resolves compat from this checkout

A copy of a member is not a member of the workspace and did not inherit its
[indices], so compat resolved from the published index and a descriptor changed
in a pull request was not the one measured (the archive member measured
libarchive's published descriptor). The copy now names this checkout when the
member declares no [indices] of its own.

* openkal compatibility: the measurement of 2026-09-17

Measured by openkal-compat run 35222831479 with mcpp 2026.9.17.3,
openkal-llvm-runtime 0.10.0 and llvm@22.1.8, the host's mingw headers installed.
x86_64-linux-gnu: 27 members run, 3 fail (cmp-module and curl name Linux kernel
headers or epoll, which openkal does not provide; expat calls arc4random_buf,
which musl does not declare). x86_64-windows-gnu, run through Wine: 15 run,
15 fail, each on a Windows or MinGW header its package includes on _WIN32.