register openkal-macos 0.12.0 and openkal-musl 0.18.0

[Sunrisepeak]

What this registers

• openkal-macos 0.12.0 — the first release of that implementation to declare [kernel-abi] provides-interfaces, derived from its own objects and diffed against its manifest by its own CI (which runs on mcpp 2026.8.27.1, three weeks older than the key, so its green run also measures the backward-compatibility claim).
• openkal-musl 0.18.0 — follows it, so a consumer's requires-interfaces is answered on macOS as it already is on Linux and Windows.

Neither changed any source.

This is registered late, and that had a visible cost

openkal-llvm-runtime 0.13.0 was merged pinning openkal-musl 0.18.0 before 0.18.0 was registered here. mcpp's openkal-cross workflow clones that repository's default branch, so the next mcpp run failed:

E_NOT_FOUND: package 'compat.openkal-musl@0.18.0' not found in the synced index
             (mcpplibs@artifact:b390b4b), synced 0 seconds ago

A consumer may not be merged ahead of the registration of what it pins — even when the consumer's own CI is green, because that CI substitutes working trees for the whole graph and therefore cannot see the gap by construction.

min_mcpp does not move

Both packages' new keys are top-level tables that an older engine ignores, and all 231 descriptors parse with the pinned 2026.9.18.3 — the descriptor grammar is unchanged.

Verification

sha256, both	recomputed from fresh downloads of the GLOBAL url — match
CN assets, both	fetched in full, cmp against GLOBAL — byte-for-byte equal
5 descriptor lints	pass
mcpp xpkg parse, all 231	pass on the pinned 2026.9.18.3

Entries land in all three platform blocks. check_platform_version_parity enforces that, having caught a linux-only insertion earlier in this wave.