Resolve the target side once, and let every translation unit read it

[Sunrisepeak]

Closes #514. Also supplies the engine facility openkal-musl#13 had named in its own source as the one it needed.

Full analysis: .agents/docs/2026-08-27-openkal-native-path-three-issues.md, carried by this pull request.

In one sentence

mcpp had already computed which directories hold the C++ ABI headers this target is built against, and delivered that set accurately — to one translation unit. Every other unit in the graph received it only if it happened to stand on a dependency edge.

This is the next layer of the family 2026.8.25.x and 2026.8.26.1 belong to. Those fixed a predicate that asked the wrong question and an answer that reached no decision. Here the answer reached one consumer and it has five.

Six defects

① The compile-side predicate	The twin of the one 2026.8.26.1 fixed on the link side. !crossTargetFlag.empty() becomes plan.targetSide.cAbi.prebuilt()
② A vocabulary mismatch in payload directory names	include/<triple>/c++/v1 is spelled in LLVM's vocabulary and looked up in mcpp's, and if (exists) makes the miss silent
③ The target side reached one unit	mcpp#514 §A. A graph-supplied layer's publicUsage now merges into every package's privateBuild
④ The cache key described the compiler, not the header set	mcpp#514 §B. A new targetHeaderSet axis
⑤ A fourth derivation of the home	active_home_xpkgs() omitted self-contained installs; find_sibling_package fell back to ~/.xlings unconditionally
⑥ Two vocabularies for a payload version	A binding names the version DECLARED; a directory is named after what that request RESOLVED to
New	[build] private_include_dirs — a package may distinguish what it is built from from what it publishes

① measured

Same machine, same compiler, same target, differing only in whether it was spelled out:

ldflags  line:  token for token identical      <- #511 fixed this side
cxxflags line:  the explicit one lost six tokens:
  --no-default-config / -nostdinc++ / payload libc++ x2 / glibc / linux-headers

⇒ Headers from one library, objects linked from another.

--no-default-config is split out of that condition and emitted unconditionally. It is not part of the payload's header set, and a cfg file is by post_install.cppm's own words "a per-machine, per-install-path artifact". This also explains why the reporter's hand-written <triple>-clang++.cfg worked around #514: it was read only because this token had gone missing.

e2e 295 states exactly this invariant and compared ^ldflags alone, so the identity failed on the next line and the test could not see it. It now compares both.

② measured

include/<triple>/c++/v1 holds one file: __config_site. Its absence reads as a broken payload, and this repository has misdiagnosed it more than once.

⑥ measured

Downloading xim:glibc@2.44
error: selected RuntimeBinding glibc@2.44.2 requires payload '.../2.44.2', but it is not installed

The criterion is refinement, not a pick by directory order: components are compared component-wise, so 2.4 does not answer 2.44; two payloads both refining one request yield nothing; and the reverse direction is refused, because accepting a payload older than the request would silently use the one the index states is not the one to install.

Criteria

unit	93 passed / 0 failed; 3 added, each confirmed to actually run — the first draft of the hostflags test SKIPPED for want of a real cfg, and now carries a fixture with ASSERT that it took effect
e2e 295	extended to cxxflags; four checks across two toolchains; exit 1 on the unfixed binary, listing the six lost tokens
e2e 304 (new)	the target side reaches a sibling dependency package — red on the unfixed binary. Asserts the reverse too: a non-layer package's directory must not spread
e2e 305 (new)	built-from and published are separable, globs included — red on the unfixed binary
denominators	all three assert CDB row counts ≥ 1, so an empty CDB cannot pass

What the pre-merge review found

Four further defects, all mine, each with an A/B showing the criterion goes red without the fix:

The cache key baked in this machine's home	The axis comment promised it would survive a different MCPP_HOME; a <store>-only rule cannot deliver that, because the ordinary toolchain's only compile token is --sysroot=<home>/registry/subos/default. Both existing tests set the axis directly, so neither exercised the relativization at all.
An empty version request returned the package root	root / "" is root, and it is a directory. Both callers reject an empty version before arriving — which is exactly why nothing would have caught it.
The two new keys meet in one package and nothing tested it	openkal-musl is that shape. Removing the key in the fixture put the overlay onto the sibling package and the root.
The CHANGELOG omitted ⑥ entirely	The defect users meet first on a clean machine.

Ecosystem cross-validation

Nine repositories, each carrying implementation rather than a CI change, all building mcpp from this branch:

openkal#13	five interfaces, SPEC clauses 3/6.3/11, SURFACE, conformance, and openkal-kit
openkal-linux#15	all five implemented, plus the three additions to openkal.process
openkal-macos#11 · openkal-windows#13	terminal and channel
openkal-opensbi#11 · openkal-uefi#8	all five declined under clause 6.1, each with a reason
openkal-musl#15	permanent absence becomes a link error; umask; copy_file_range; pipe
openkal-llvm-runtime#7	__config_site reconciliation, and the cross-validation this repository never had

Green is not the criterion; the under review: line is — checked per job.

Compatibility

• kCacheEpoch is not bumped. An older entry is a miss, not a hazard: inputs_match compares inputs.toolchain as one object.
• private_include_dirs degrades on an older engine. Measured on 2026.8.26.2: silently accepted in a dependency's manifest, a warning in a root manifest, exit 0 either way. The one place it does not hold is a published xim descriptor's target_cfg, where an unrecognised sub-key is fatal — documented.
• Toolchain::cAbiPrebuilt defaults to true, so every host-targeting build behaves exactly as before.
• The xlings pin is deliberately not moved. Bumping it was attempted and reverted with the measurement: the bootstrap engine installs glibc@2.44 while the newly-pinned vendored xlings computes the binding as 2.44.2, and the request then exceeds what is installed. It is self-healing in one order only, so it belongs in the release after this one — the rule the index states in its own source: the consumer ships first.