[Bug] CMake version probe and build run outside the workspace, breaking version-manager (mise/asdf) shims

### Brief Issue Summary

# Brief Issue Summary

When `cmake` is provided by a directory-based version manager (mise, asdf, vfox, ...), the extension fails with a bad/missing CMake executable, for example:
```
Bad CMake executable: "". Check to make sure it is installed or the value of the "cmake.cmakePath" setting contains the correct path
```

If I try to point cmakePath to the correct mise shim (`"cmake.cmakePath": "${userHome}/.local/share/mise/shims/cmake"`) I still get an error:
```
[proc] Command output on standard error: mise ERROR No version is set for shim: cmake
```

even though `cmake` resolves fine from a terminal opened in the project.

## Related issues

- #4603 (mise, "Bad CMake executable, even though it's available on the path")
- #3359 (asdf, "Bad executable")
- #1731 (What is the Working Directory During Configure?)
- There is also a [third party extension](https://github.com/hverlin/mise-vscode/) that fixes it, but it would be much better for this to work out of the box

# Root cause

Several cmake child processes are spawned without a `cwd`, so they inherit the extension host's `process.cwd()`, which is not guaranteed to be the workspace folder. Version-manager shims resolve the tool version by walking up from the current working directory, so when the host cwd is outside the project the shim resolves no version and fails.

Source (v1.23.52 / current main):

- src/cmakeExecutable.ts `getCMakeExecutableInformation` runs the version and
`-E capabilities` probes with `{ showOutputOnError, environment }` — no cwd.
- src/proc.ts `execute` only sets a spawn cwd when one is passed; otherwise Node
`child_process.spawn` defaults to `process.cwd()`.
- The build path (src/drivers/cmakeDriver.ts `_doCMakeBuild`) and the task build
path (src/cmakeTaskProvider.ts) also spawn cmake without a cwd. Configure works
because it already passes `cwd: options?.cwd ?? binaryDir`.

This is launch-dependent, which is why it commonly appears on Remote-WSL when the editor is started from the Windows GUI (extension host cwd = home) rather than via `code .` inside the repo.

# Reproduction (self-contained, no mise/asdf needed)

[vscode-cmake-tools-shim-cwd-repro.zip](https://github.com/user-attachments/files/30339150/vscode-cmake-tools-shim-cwd-repro.zip)

A tiny fake shim that mimics a version manager (only runs cmake when its $PWD is
inside the project) reproduces it deterministically:

1. `.vscode/settings.json`: `"cmake.cmakePath": "${workspaceFolder}/shim/cmake"`
2. `shim/cmake` (bash): resolve/exec real cmake only if `$PWD` is inside the project; otherwise print "No version is set for shim: cmake" and exit 1.
3. Fully quit the editor, then launch from outside the project (`cd ~ && code /path/to/repro`) -> configure-on-open fails with the shim error. For contrast, `cd repro && code .` works on macOS (but not on Windows through WSL).

## Expected

CMake Tools' cmake invocations run in the workspace/project directory so version-manager shims resolve the tool version, independent of how the editor was launched.

## Actual

The version probe (and build/task-build) run in the extension host's cwd; when that is outside the project, the shim reports no version and CMake Tools reports a bad/missing CMake executable.

# Proposed fix

Give the cmake invocations a project-relative cwd (probe -> workspace/project folder; build -> binaryDir, matching configure; a `sourceDir` default in the driver's `executeCommand`).

# Environment

- OS: macOS / Linux / WSL
- CMake Tools: 1.23.52
- cmake provided via mise/asdf (directory-based version manager)

### CMake Tools Diagnostics

```shell
{
"os": "darwin",
"vscodeVersion": "1.128.0",
"cmtVersion": "1.23.52",
"configurations": [
{
"folder": "/Users/df/Developer/tractive/tracker-application",
"cmakeVersion": "unknown",
"configured": false,
"generator": "unknown",
"usesPresets": false,
"compilers": {}
}
],
"cpptoolsIntegration": {
"isReady": false,
"hasCodeModel": false,
"activeBuildType": "",
"buildTypesSeen": [],
"requests": [],
"responses": [],
"partialMatches": [],
"targetCount": 0,
"executablesCount": 0,
"librariesCount": 0,
"targets": []
},
"settings": [
{
"communicationMode": "automatic",
"useCMakePresets": "auto",
"configureOnOpen": true
}
]
}
```

### Debug Log

```shell
CMake isn't found so there is no relevant log, the error is:

Bad CMake executable: "". Check to make sure it is installed or the value of the "cmake.cmakePath" setting contains the correct path
```

### Additional Information

_No response_

Start with src/cmakeExecutable.ts and getCMakeExecutableInformation, then trace cwd handling through src/proc.ts execute. Inspect _doCMakeBuild in src/drivers/cmakeDriver.ts and the build path in src/cmakeTaskProvider.ts, comparing them with configure's cwd behavior. Done means version probes, builds, and task builds run from the project-relative directories so directory-based version-manager shims resolve consistently.

Written by the indexing model from the issue text.