fix(toolchain): the msvc payload's location is known, not inferred

    error: msvc payload installed at
      'C:\Users\...\xpkgs\xim-x-msvc\14.44.35207\VC',
      but no cl.exe under VC/Tools/MSVC/14.44.35207

Note the `\VC` on the end. `XpkgPayload::root` treats the version directory
as the root only when it directly contains bin/ include/ lib/, and otherwise
descends into a lone subdirectory (package_fetcher.cppm:1027). An installed
msvc payload has exactly one entry -- `VC/` -- so the root came back one
level too deep and a perfectly good toolset read as missing.

That heuristic is right for the payloads it was written for; it is simply not
an answer to "where is this package". The answer is (store, name, version),
and all three are known at both call sites: `xim_tool(env, name, version)`
gives the version directory outright. `resolve_xpkg_path` still does the
installing -- it just stops being asked where.

Found on the first e2e run where the install actually succeeded. Every
earlier attempt died in the recipe, so this was standing behind three other
defects the whole time.

The test pins both directions: the version directory resolves, and the `VC`
subdirectory does NOT -- an implementation that searched upward from whatever
it was handed would pass the first assertion and fail the second.

Author: speak-agent

src/build/prepare.cppm

@@ -1320,12 +1320,19 @@ prepare_build(bool print_fingerprint,
         // (cl.exe is four levels deeper) and the ELF post-install fixup
         // (there is nothing to patchelf on a PE toolchain).
         if (spec->family == mcpp::toolchain::Family::Msvc) {
+            // Not `payload->root`: that field is the fetcher's guess at where
+            // the useful tree starts, and it descends into a lone
+            // subdirectory when the version dir has no bin/ include/ lib/.
+            // An msvc payload's only entry is `VC/`, so the guess lands one
+            // level too deep. (store, name, version) is known — use it.
+            auto verDir = mcpp::xlings::paths::xim_tool(
+                mcpp::config::make_xlings_env(**cfg), pkg.ximName, pkg.ximVersion);
             auto inst = mcpp::toolchain::msvc::installation_at(
-                payload->root, pkg.ximVersion);
+                verDir, pkg.ximVersion);
             if (!inst) {
                 return std::unexpected(std::format(
                     "msvc payload at '{}' has no cl.exe under VC/Tools/MSVC/{}",
-                    payload->root.string(), pkg.ximVersion));
+                    verDir.string(), pkg.ximVersion));
             }
             explicit_compiler = inst->clPath;
             mcpp::ui::info("Resolved", std::format(

src/toolchain/lifecycle.cppm

@@ -618,14 +618,26 @@ export int toolchain_install(const mcpp::config::GlobalConfig& cfg,
         // VC/Tools/MSVC/<ver>/bin/Hostx64/x64, and there is nothing to
         // patchelf on a PE toolchain.
         if (spec->family == mcpp::toolchain::Family::Msvc) {
+            // NOT `payload->root` — that is a GUESS, and it guesses wrong
+            // here. resolve_xpkg_path calls the version directory the root
+            // only when it directly contains bin/ include/ lib/; otherwise it
+            // descends into a lone subdirectory. An installed msvc payload
+            // has exactly one entry, `VC/`, so the "root" comes back as
+            // …/14.44.35207/VC and the toolset then looks like it is missing.
+            //
+            // The location is not something to infer: it is (store, name,
+            // version), and all three are known here. resolve_xpkg_path above
+            // is what INSTALLS; this is what says where.
+            auto verDir = mcpp::xlings::paths::xim_tool(
+                mcpp::config::make_xlings_env(cfg), pkg.ximName, pkg.ximVersion);
             auto inst = mcpp::toolchain::msvc::installation_at(
-                payload->root, pkg.ximVersion);
+                verDir, pkg.ximVersion);
             if (!inst) {
                 mcpp::ui::error(std::format(
                     "msvc payload installed at '{}', but no cl.exe under "
                     "VC/Tools/MSVC/{} — the payload is not what this version "
                     "claims to be",
-                    payload->root.string(), pkg.ximVersion));
+                    verDir.string(), pkg.ximVersion));
                 return 1;
             }
             msvc_print_detected(*inst, "Installed");

tests/unit/test_toolchain_msvc.cpp

@@ -234,6 +234,28 @@ TEST(MsvcManaged, ResolvesTheDeclaredToolsetAndNotItsNeighbour) {
     EXPECT_EQ(newer->toolsVersion, "14.52.36629");
 }
 
+TEST(MsvcManaged, TheVersionDirIsTheRootNotItsLoneSubdirectory) {
+    // A real installed payload has exactly ONE entry: `VC/`. The fetcher's
+    // `XpkgPayload::root` treats the version directory as the root only when
+    // it directly contains bin/ include/ lib/, and otherwise descends into a
+    // lone subdirectory -- so for msvc it hands back `<ver>/VC`, and the
+    // toolset then looks missing on a payload that installed perfectly.
+    //
+    // Pinning both sides here: the version directory resolves, and the `VC`
+    // subdirectory does NOT. The second half is what makes this a test rather
+    // than a restatement -- an implementation that searched upward from
+    // whatever it was given would pass the first and fail this.
+    FakeToolset t{"verdir"};
+    t.add_toolset("14.44.35207");
+
+    auto ok = msvc::installation_at(t.root, "14.44.35207");
+    ASSERT_TRUE(ok.has_value()) << "the version directory must be the root";
+
+    EXPECT_FALSE(msvc::installation_at(t.root / "VC", "14.44.35207").has_value())
+        << "a caller handing in the VC subdir is passing the wrong thing, and "
+           "must be told so rather than quietly rescued";
+}
+
 TEST(MsvcManaged, AbsentToolsetIsNulloptNotASubstitute) {
     FakeToolset t{"absent"};
     t.add_toolset("14.44.35207");