Run cmake subprocesses in the project directory so version-manager shims resolve correctly

[Daniele Formichelli (danieleformichelli)]

This change addresses item #5005

This changes visible behavior

The following changes are proposed:

• kits/kit.ts: probe cmake from the workspace folder during Clang/MSVC kit scanning (runs for any clang binary, so it hits shim users on Linux/macOS too).
• Run the cmake subprocesses launched by the extension inside the project directory instead of inheriting the extension host's process.cwd().
• Thread an optional cwd through getCMakeExecutableInformation(...) (the cmake --version / -E capabilities probe) and pass the workspace/project folder from every caller (extension.ts, cmakeProject.ts, debuggerScriptDriver.ts).
• Default the working directory of driver subprocesses to sourceDir, the build invocation to binaryDir, and build tasks to binaryDir || sourceDir || workspaceFolder.
• Default the CMake script debugger child process cwd to the project folder.

The purpose of this change

Users whose cmake is provided by a directory-based version manager (mise, asdf, vfox, ...) install a shim on PATH. These shims resolve the tool version by walking up from the current working directory to find the nearest config file. They do not have a "current" version baked in.

Today the extension launches cmake (the version/capabilities probe, the build, and the script debugger) without setting a cwd, so the child inherits the extension host's process.cwd(). Depending on how the editor was launched (e.g. from the OS GUI, Dock, or a Remote-WSL host started from the Windows GUI), that directory is often the user's home folder — outside the project. The shim then has no config to resolve against and fails, e.g.:

mise ERROR No version is set for shim: cmake

The result is that configuration intermittently succeeds (some paths already pass a cwd) while the version probe or the build fails, with an error that looks like a broken toolchain rather than a cwd issue.

Running these subprocesses in the project directory is the natural, correct behavior for a project-scoped build tool and makes shim-based toolchains resolve reliably, regardless of how the editor process was started.

Other Notes/Information

• Scope is intentionally minimal: each call site defaults cwd only when the caller didn't already specify one, so existing behavior for explicitly-set working directories is unchanged.
• The change is a no-op for users on absolute cmake paths or non-shim installs, since the working directory doesn't affect how those binaries resolve.
• One related probe, checkDebugger in src/debug/debugger.ts, still runs without a cwd. It was deliberately left out of this PR to keep the change focused on the cmake execution paths; happy to include it if maintainers prefer.
• A minimal standalone reproduction (a fake cwd-sensitive cmake shim + a tiny CMake project + a script showing the shim succeeding in-project and failing from $HOME) is available and can be linked/attached on request.

[Daniele Formichelli (danieleformichelli)]

@microsoft-github-policy-service agree company="Bending Spoons"

[Hannia Valera (hanniavalera)]

Daniele Formichelli (@danieleformichelli) Thank you for contributing this fix! It is quite appreciated! I reviewed the subprocess working-directory changes across CMake probing, builds, tasks, kit scanning, and script debugging, with particular attention to multi-root and nested-source projects, external build directories, version-manager shim caching, and regression risk for existing CMake workflows.

The overall direction is sound and directly addresses the underlying problem in #5005. I left a few comments about using the source directory for shim resolution and making the executable-information cache project-context aware. Thanks again for the clear explanation, focused implementation, and work to improve the experience!