A host tool's sub-build resolves its own toolchain, not the one its key records, so a workspace pinned to one LLVM installs a second

[speak-agent]

Observed

GalTranslPP's workspace root states [toolchain] windows = "llvm@22.1.8", and every member builds with it. Two members take executables through tool edges (tools = ["Updater"], tools = ["runtime_stage"]). On a fresh runner, the sub-build of each tool reports:

    Building host tool updater:Updater from updater v3.1.1 (once per package source and host toolchain)
   First run no toolchain configured — installing llvm@20.1.7 as default
    Resolved llvm@20.1.7 → @mcpp/registry/data/xpkgs/xim-x-llvm/20.1.7/bin/clang++.exe

(mcpp emit build-database, mcpp 2026.9.26.2, Sunrisepeak/GalTranslPP run 36260450278.)

Consequences:

1. A project pinned to one LLVM installs a second one, and compiles a second std module, before its first build. This is part of the 4.8 minutes that a first emit takes.
2. The tool-store key does not describe the binary it stores. The key records the consumer's host toolchain (key.compilerIdentity from hostTc, src/build/prepare.cppm near line 10324). The sub-build does not receive a toolchain (sub.tool_chain holds the chain of tool names) and resolves its own.

Request

The sub-build of a host tool compiles with the host toolchain that its key records, which is the one the consumer resolved for build.mcpp. If that is not wanted, the key should record the toolchain that the sub-build actually used.