fix(mysql-connector-cpp): the hook cannot know the consumer's stdlib — measured, then stated

[Sunrisepeak]

What changed since the first push

The first push asked a question — does MCPP_CXX_STDLIB reach an xlings install hook? — and shipped a probe that logged the answer either way and applied -stdlib=libc++ if the answer was yes.

The answer is no. This PR now carries the conclusion instead of the attempt.

The evidence, at three levels

level	finding
measured	11:46:18 MCPP_CXX_STDLIB=nil on workspace (linux llvm 0/4), link failed as before
only setter	src/build/build_program.cppm: e.emplace_back("MCPP_CXX_STDLIB", env.cxxStdlib) — exported when mcpp runs a build program
call surface	make_xlings_env builds xlings::Env{binary, home, projectDir}; install_packages is invoked with XLINGS_HOME and PATH. No toolchain crosses

Both routes I assumed were open are closed

• "let its CMake step use libc++" — needs the consumer's choice, which by construction does not reach the hook.
• "refuse the libc++ leg like llamacpp" — llamacpp does it with mcpp::cxx_stdlib() in its build program, in its own repo. An inline descriptor has no such place, and [target.'cfg(...)'] self-gating has a platform axis and no standard-library axis (a cfg selector is not a platform).

What this does instead

The descriptor stops being silent. It now states that these are static libraries built by CMake with the system compiler, that std::__cxx11:: therefore crosses the boundary into the consumer, and that a libc++ consumer cannot use them — where a user reads it rather than where the linker says it.

The probe stays. One log line; it is the evidence for level 1, and the day mcpp passes the variable through, it reports that and the fix becomes the three lines directly below it.

validate.yml keeps the member off the llvm leg, with the reasoning written at the point that does the skipping. In CI and not in a descriptor for a reason worth saying out loud: the leg is the only layer that knows which standard library is in play.

SKIPPED, NOT MARKED GREEN — the incompatibility is real for users on a libc++ toolchain. This stops CI re-measuring a known answer every run; it does not claim the combination works.

One consequence handled: linux llvm 0/4 holds mysql-connector-cpp and nothing else (386s, 100% of that shard), so skipping it empties the shard. The downstream message said "No workspace member affected by this change", which would now be false; it covers both cases and points at the line that says which.

Verification

• luac -p clean on the descriptor
• ruby -ryaml parses the workflow
• the rendered shell fragment tested standalone:

  skipping 'mysql-connector-cpp' on the llvm leg: static libs are built against the system stdlib; …
  MEMBERS=[eui-neo-window vulkan]
  

• the default leg is untouched (the whole block is inside if [ "$toolchain" = "llvm" ])

The real fix is upstream of this repo

Install hooks need the consumer's standard library, or a source-built static package can never match its consumer's ABI. Filing that against mcpp; when it lands, the validate.yml entry comes out and the descriptor does the work.