fix(toolchain): resolve .exe tool names on Windows; collapse the host/target gate

Two changes to one code region, which is why they share a commit — splitting
them would leave a middle state that does not compile.

B1 — the frontend was unfindable on a Windows host.
  musl payload candidates were { "<triple>-g++", "g++" }, resolved with
  filesystem::exists. On Windows the file is `<triple>-g++.exe`, so exists()
  said no and a payload that installed perfectly was then unusable. The mingw
  branch has carried the .exe spelling since it shipped; this branch never did,
  because nothing had ever installed a musl payload on a Windows host. Same
  omission in archive_tool's musl branch (`<triple>-ar`), fixed alongside.
  .exe is listed first: on a case-insensitive filesystem both spellings match
  and the executable is the one we want.

host_can_serve — one derivation instead of two.
  "Can this host serve that target" was computed independently in two places:
  registry.cppm picking the xim payload, and lifecycle.cppm deciding whether
  `toolchain list` may show a target as available. They had already drifted —
  the payload side would resolve a windows-hosted musl package that the
  availability side declared impossible. The predicate now lives once, in
  registry.cppm next to the payload resolution it has to agree with, and
  lifecycle calls it.

  It also gains the case this series exists for: a non-Linux host may serve a
  Linux target when the payload is self-contained (musl) and built for that
  host's own arch. Deliberately narrow — the canadian-cross payload is built
  per host arch, and macOS has no Linux-targeting payload at all, so both stay
  unserviceable rather than failing at install time.

available_toolchain_indexes now lists the windows-hosted cross under the same
name to_xim_package() derives (`<triple>-gcc`), so the Available listing and
the install path cannot disagree.

Refs .agents/docs/2026-08-03-windows-host-linux-cross-design.md §1.2, §1.3 (B1)

Author: Sunrisepeak

src/toolchain/lifecycle.cppm

@@ -368,15 +368,12 @@ export int toolchain_list(const mcpp::config::GlobalConfig& cfg) {
 
     // Vocabulary rows not covered by an installed payload. Only list a
     // verified target as "available" when this host can actually install it.
+    //
+    // The predicate lives in registry.cppm next to the payload resolution it
+    // must agree with — this used to be a second, independent derivation of
+    // the same question and the two had already drifted apart.
     auto installable_here = [&](const mcpp::toolchain::triple::Triple& t) {
-        if (t.os == "linux")
-            return mcpp::platform::is_linux
-                && (t.is_musl() || t.arch == hostT.arch);
-        if (t.is_windows_gnu())
-            return mcpp::platform::is_linux || mcpp::platform::is_windows;
-        if (t.os == "windows") return bool(mcpp::platform::is_windows);
-        if (t.os == "macos")   return bool(mcpp::platform::is_macos);
-        return false;
+        return mcpp::toolchain::host_can_serve(t);
     };
     for (auto& info : mcpp::toolchain::triple::known_targets()) {
         bool covered = std::any_of(targetRows.begin(), targetRows.end(),

src/toolchain/registry.cppm

@@ -113,6 +113,18 @@ bool spec_matches_payload(const ToolchainSpec& def,
 // (`[toolchain] … = "system"`) is a separate, older mechanism.
 bool is_system_toolchain(const ToolchainSpec& spec);
 
+// Can THIS host serve that target — is there an installable payload for the
+// (host, target) pair? Empty target = host target, always serviceable.
+//
+// THE single derivation of that question. It used to be worked out twice and
+// independently: here, when picking the xim payload, and again in
+// lifecycle.cppm when deciding whether `toolchain list` may show a target as
+// `available`. Two derivations of one decision is how adding a target turns
+// into a build failure instead of a missing row — the pair had already drifted
+// once (the payload side would happily resolve a windows-hosted musl package
+// that the availability side declared impossible).
+bool host_can_serve(const triple::Triple& target);
+
 // xim index names to query for the Available section, with the family each
 // one contributes versions to. Host-conditional: a host only lists payloads
 // it can install.
@@ -225,7 +237,19 @@ XimToolchainPackage to_xim_package(const ToolchainSpec& spec) {
         bool native = mcpp::platform::is_linux
                    && t.arch == mcpp::platform::host_arch;
         pkg.ximName = native ? "musl-gcc" : t.str() + "-gcc";
-        pkg.frontendCandidates = { t.str() + "-g++", "g++" };
+        // Frontend candidates are resolved with filesystem::exists, so on a
+        // Windows host the bare name never matches — the file on disk is
+        // `<triple>-g++.exe`. The mingw branch below has carried the `.exe`
+        // spelling since it shipped; this one had not, which made a
+        // windows-hosted musl payload install fine and then be unusable.
+        // `.exe` first: on a case-insensitive filesystem both would match, and
+        // the executable is the one we want.
+        if constexpr (mcpp::platform::is_windows) {
+            pkg.frontendCandidates = { t.str() + "-g++.exe", t.str() + "-g++",
+                                       "g++.exe", "g++" };
+        } else {
+            pkg.frontendCandidates = { t.str() + "-g++", "g++" };
+        }
         return pkg;
     }
 
@@ -299,6 +323,32 @@ bool is_system_toolchain(const ToolchainSpec& spec) {
     return spec.family == Family::Msvc;
 }
 
+bool host_can_serve(const triple::Triple& target) {
+    if (target.empty()) return true;              // host target
+
+    if (target.os == "linux") {
+        if constexpr (mcpp::platform::is_linux) {
+            // musl payloads are self-contained, so any arch is reachable; a
+            // glibc target additionally needs the host-native sysroot payloads
+            // (xim:glibc / xim:linux-headers), which only exist for this arch.
+            return target.is_musl() || target.arch == mcpp::platform::host_arch;
+        }
+        // Non-Linux host: only the self-contained musl payloads can work at
+        // all (nothing else would find a C library). Today exactly one such
+        // payload exists — the windows-hosted canadian cross, built per host
+        // arch — so an arch-crossing combination stays unserviceable until one
+        // is published. macOS has no Linux-targeting payload at all.
+        return mcpp::platform::is_windows
+            && target.is_musl()
+            && target.arch == mcpp::platform::host_arch;
+    }
+    if (target.is_windows_gnu())
+        return mcpp::platform::is_linux || mcpp::platform::is_windows;
+    if (target.os == "windows") return bool(mcpp::platform::is_windows);
+    if (target.os == "macos")   return bool(mcpp::platform::is_macos);
+    return false;
+}
+
 std::vector<AvailableIndex> available_toolchain_indexes() {
     std::vector<AvailableIndex> out{
         { "gcc",      Family::Gcc },
@@ -307,10 +357,16 @@ std::vector<AvailableIndex> available_toolchain_indexes() {
     };
     // The Windows-PE gcc payload is host-split at the distribution layer
     // (§4.3); each host lists the package it would actually install.
-    if constexpr (mcpp::platform::is_windows)
+    if constexpr (mcpp::platform::is_windows) {
         out.push_back({ "mingw-gcc", Family::Gcc });
-    else if constexpr (mcpp::platform::is_linux)
+        // The windows-hosted canadian cross to Linux. Named by triple, exactly
+        // as to_xim_package() derives it (`<triple>-gcc`), so the Available
+        // listing and the install path cannot disagree about the package name.
+        out.push_back({ std::string(mcpp::platform::host_arch) + "-linux-musl-gcc",
+                        Family::Gcc });
+    } else if constexpr (mcpp::platform::is_linux) {
         out.push_back({ "mingw-cross-gcc", Family::Gcc });
+    }
     return out;
 }
 
@@ -354,7 +410,15 @@ std::filesystem::path archive_tool(const Toolchain& tc) {
     std::string arName = !tc.targetTriple.empty()
         ? tc.targetTriple + "-ar"
         : "x86_64-linux-musl-ar";
-    auto muslAr = tc.binaryPath.parent_path() / arName;
+    auto dir = tc.binaryPath.parent_path();
+    // Same `.exe` reasoning as the frontend candidates above: a windows-hosted
+    // musl cross payload ships `<triple>-ar.exe`. Try it first, then the bare
+    // name (which is what every ELF host has).
+    if constexpr (mcpp::platform::is_windows) {
+        auto muslArExe = dir / (arName + ".exe");
+        if (std::filesystem::exists(muslArExe)) return muslArExe;
+    }
+    auto muslAr = dir / arName;
     if (std::filesystem::exists(muslAr)) return muslAr;
     return {};
 }