fix(build.mcpp): state the deployment target even when trusting clang's cfg; drop -x for cl

Two failures the local runs could not see, both the same shape — a branch
that was dead while the MSVC gate existed, or a platform this machine is not.

host_compile_tokens returned early on the trust-cfg path, which on macOS IS
the build.mcpp path: no clang flags and no deployment target, so the std BMI
(built for 14.0) was rejected by a TU compiled without it. Trusting the cfg
means contributing no include paths or stdlib selection — not contributing
nothing. The deployment target is emitted regardless now, which is what the
hand-written host_base_flags did deliberately ("FIRST and unconditionally")
before this refactor absorbed it.

The `-x none` before the module objects was unconditional and harmless only
while cl.exe could not reach it. Removing the module gate made the dead
branch live, and cl answered `D9002: ignoring unknown option '-x'` — after
compiling the .ifc and reaching the link, which is further than build.mcpp
has ever gone under MSVC.

Author: Sunrisepeak

src/build/build_program.cppm

@@ -666,10 +666,13 @@ std::expected<void, std::string> run_build_program(
     for (auto f : dial.forceCxxLangArgv) compileArgv.emplace_back(f);
     compileArgv.push_back(src.string());
     if (usesModule || !stdObjects.empty()) {
-        // Link the module objects (GNU: reset the input language first so the
-        // .o isn't treated as C++ source; cl.exe infers by extension and is
-        // unreachable here anyway, gated above).
-        compileArgv.push_back("-x"); compileArgv.push_back("none");
+        // Link the module objects. GNU drivers need the input language reset
+        // first, or the .o that follows `-x c++` is handed to the frontend as
+        // C++ source; cl.exe has no `-x` at all and infers from the extension.
+        // This used to be unconditional and was only harmless while MSVC could
+        // not reach it — removing that gate made the dead branch live, and cl
+        // answered with `D9002: ignoring unknown option '-x'`.
+        if (!msvcHost) { compileArgv.push_back("-x"); compileArgv.push_back("none"); }
         if (usesModule) compileArgv.push_back(mcppModuleObject.string());
         for (auto& so : stdObjects) compileArgv.push_back(so);
     }

src/toolchain/hostflags.cppm

@@ -126,19 +126,28 @@ std::vector<std::string> host_compile_tokens(const Toolchain& tc,
         dm.hasCfg && (opt.cfgBypass == HostFlagOptions::CfgBypass::Always
                       || mcpp::platform::is_linux);
 
+    // Trusting the cfg means contributing no include paths, stdlib selection
+    // or runtime choices — it already carries them. It does NOT mean
+    // contributing nothing: the deployment target still has to be stated (see
+    // below), which is why this suppresses the two blocks rather than
+    // returning early.
+    const bool trustCfg = !bypassCfg && dm.hasCfg;
+
     if (bypassCfg) {
         for (auto& t : dm.compile_tokens(esc, opt.clangStdlibSelect))
             out.push_back(t);
-    } else if (dm.hasCfg) {
-        // Trusting the cfg means adding nothing at all: it already carries
-        // the include paths, the stdlib selection and the runtime choices.
-        return out;
     }
 
+    // Unconditional on macOS, cfg or no cfg. clang refuses to load a module
+    // built for a different deployment target, and this result feeds every
+    // compile that touches one — the bundled mcpp module's precompile, its
+    // object step, and the build.mcpp compile. Skipping it on the trust-cfg
+    // path is exactly the mismatch e2e 181 catches: the std BMI is built for
+    // 14.0 while the TU importing it is not.
     if (mcpp::platform::is_macos && !opt.macosDeploymentTarget.empty())
         out.push_back("-mmacosx-version-min=" + opt.macosDeploymentTarget);
 
-    if (bypassCfg || lm.mode != CLibMode::None)
+    if (!trustCfg && (bypassCfg || lm.mode != CLibMode::None))
         for (auto& t : lm.compile_tokens(esc)) out.push_back(t);
 
     return out;