feat(toolchain): gcc@system is rejected, and says what to do instead - #441

…#437) (#442)

* docs(review): §1's premise was invented — correct it

The first draft read `is_system_toolchain()` being gated on `Family::Msvc`
as an asymmetry and proposed supporting `gcc@system`. That is backwards.
xlings is a user-space OS and mcpp is built on it to keep host dependence to
a minimum: a toolchain comes from a payload, which is what makes "the
manifest says 14.44.35207" true on every machine rather than on the one that
happened to have it. `msvc@system` is a Windows concession — Visual Studio is
often already installed and cannot always be redistributed — not a general
capability with three families missing.

`gcc@system` was never a feature or a request. I invented it, and after being
corrected on the direction I wrote an explicit rejection for the spelling I
had invented, which is scope grown out of my own mistake. That PR (#441) is
closed.

Its message was also factually wrong: it claimed "only msvc@system exists",
while prepare.cppm:1376 keeps a deliberate bare-`system` escape hatch for the
PATH compiler. The one place host dependence IS offered is spelled with no
family at all — recorded here so the next review does not read it as a
missing capability either.

What survives is the finding that never depended on any of that: one platform
exception spread across 26 branches (13 in lifecycle.cppm, 13 in
prepare.cppm, zero for gcc/llvm/mingw), three duplicated spellings of the
same layout rule, and a resolution comment claiming 4 steps for a chain with
9 inputs. The remedy is to resolve Origin ONCE and dispatch on it — contain
the exception, do not spread or generalise it.

* fix(toolchain): the host helper must link the way the main build does (#437)

On macOS a project builds and its `build.mcpp` does not — same toolchain,
same environment, two link paths disagreeing.

The main build deliberately forces `-fuse-ld=lld` there, and flags.cppm says
why in its own words: "Xcode 15.4's ld aborting at launch on macos-14 CI when
its libc++ resolution was diverted". The host helper takes the trust-cfg
branch in hostflags.cppm, which returns NO link tokens, so clang++ falls back
to Xcode's /usr/bin/ld. That binary is itself a C++ Mach-O linked against
libc++, running inside the DYLD_* the payload toolchain sets up, so dyld
resolves ITS libc++ to the payload's copy — which lacks __ZdaPv, and ld
aborts before linking anything.

The cfg picks runtimes; it has never picked a linker. So trusting it is right
and incomplete, and the fix is to keep trusting it while still naming the
linker on macOS. lld ships with the very toolchain doing the compile, so it
cannot be diverted to a libc++ it was not built against.

This is the same shape as the rest of this round: one rule with two
implementations, one of which knows something the other does not — like the
three duplicated spellings in the review's §1 and doctor's fourth copy of the
payload layout in §3b.

Root cause and reasoning recorded in
.agents/docs/2026-08-13-build-optimization-status.md §9a-3, which previously
stopped at "not guessing further, cannot reproduce on Linux"; the review doc
picks it up as §3e.

No unit test: the decision is inside `if constexpr (is_macos)` and compiles
out on the platform CI would run one on, so the test could not fail. The gate
is the macOS e2e suite, where 11 tests carry a build.mcpp.

* docs(review): record what landed today and what deliberately did not

The four open items all move a spec/schema layer or cross repositories, and
none of them belongs in a release window. Each is written up to the point
where it can be started directly.

---------

Co-authored-by: speak-agent <248744407+speak-agent@users.noreply.github.com>