Ships the round that made msvc@<toolset> actually work end to end, plus #437.

What this release contains

The managed MSVC toolchain now completes its whole lifecycle on a real Windows runner:

PASS: msvc@14.44.35207 installs, builds, stays distinct from msvc@system, and removes

Getting there took nine layers, each only reachable once the one before it was fixed — and every layer had been green in CI:

Also fixed here (from the architecture review, .agents/docs/2026-08-16-toolchain-architecture-review.md):

• mcpp doctor could not see an installed msvc toolset that toolchain list showed — the pre-fix(toolchain): an installed msvc toolset did not appear in toolchain list #436 layout lookup, fourth copy
• has_usable_msvc() gated three decisions on "this machine has VS", diverting a box with a pinned toolset to mingw
• a default /MD build could not start on a clean Windows box: vcruntime140.dll is not an OS component, and the payload's copy was downloaded and never used
• toolchain default accepted a directory that merely exists

And #437: on macOS any project carrying a build.mcpp failed to build, because the main build forces -fuse-ld=lld and the host helper did not — same toolchain, same environment, two link paths disagreeing.

Changelog accuracy

One entry in [Unreleased] described the removal fix as renaming the payload directory. That premise was wrong and CI disproved it: Windows renames an open file happily and refuses to rename a directory containing one. The entry now describes what actually ships — move the files aside, delete the emptied tree, and treat "no files remain" as removed.