Feature Request: Support WSL path translation when invoking Windows bazel.exe from WSL

**Subject: Feature Request: Support WSL path translation when invoking Windows `bazel.exe` from WSL**

### Summary

Hello maintainers,

I am trying to set up a development environment on Windows using `code-server` running inside WSL (Windows Subsystem for Linux). This setup is a workaround for `code-server`'s limited native Windows support and works quite well.

The workflow involves running `code-server` in a WSL distribution and using WSL's interoperability feature to call the native Windows `bazel.exe` for builds. While the build process itself works, the Bazel VS Code extension does not correctly translate file paths between the Windows and WSL filesystems.

### The Workflow & Problem

1. **Environment**:
* **Host OS**: Windows
* **Development Environment**: WSL (e.g., Ubuntu)
* **IDE**: `code-server` (running inside WSL)
* **Build Tool**: `bazel.exe` (the native Windows executable, called from within WSL)

2. **Steps**:
* I open my project located on the Windows filesystem (e.g., `C:\work\my-project`) within the `code-server` instance. The path inside WSL is `/mnt/c/work/my-project`.
* I use the Bazel VS Code extension to run a build or a test.
* The extension correctly invokes `bazel.exe` on the Windows host.

3. **Actual Behavior (The Problem)**:
* When Bazel returns an error or a file path, it uses the Windows format (e.g., `C:\work\my-project\src\main.cc`).
* The Bazel extension does not seem to recognize this as a valid path within the WSL context, because it's expecting a Linux-style path (`/mnt/c/work/my-project/src/main.cc`).
* As a result, features like "click to navigate to file" or path-based error reporting do not work.

4. **Expected Behavior**:
* The extension should detect that it is running in a WSL environment and calling a Windows executable.
* It should automatically translate Windows-style paths from Bazel's output (like `C:\work\...`) into their corresponding WSL paths (`/mnt/c/work/...`) before processing them.

### Motivation

Adding support for this path translation would enable a very powerful and seamless workflow for Windows developers. It would allow us to leverage `code-server` for remote development on Windows machines while still using Bazel as the underlying build system. This would be a fantastic enhancement for the Windows-based Bazel community.

Thank you for considering this feature request and for your great work on this extension

screenshot:

No source files or tests are named. Start by locating the extension's handling of Bazel output paths and process environment detection, then reproduce the WSL workflow with a Windows bazel.exe. Done means Windows paths from Bazel output are converted to corresponding WSL paths for navigation and path-based error reporting.

Written by the indexing model from the issue text.