System32 shadows PATH

### Description of the bug:

While trying to build my Javascript code with `rules_js` I noticed that a few actions that fetch `.tar.bzip2` files and unzip them end up hanging forever on my Windows machine and Github CI windows runners. I eventually tracked down the issue and found that `CreateProcessW` allows `System32` to completely clobber whatever is on the PATH with little recourse for overriding it. This breaks because `System32` has `bash`, `tar`, and a few other unix utilities that seem to irreversibly shadow the PATH.

I suspect that the the reason this doesn't affect some people is that they may have never installed WSL on their machines. I don't know for sure, but I think WSL left those behind when I had it installed briefly because I don't see them on all my Windows machines.

I'm not really sure what the fix is here. `rctx.execute(rctx.which("tar"))` works because Bazel manually searches the PATH rather than delegating out to the OS. But adding a PATH lookup to every `execute` seems not ideal either. Not really sure what the path forward here is, but this definitely seems like an avenue that could cause some subtle bugs on cross platform builds.

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

use `rctx.execute(['tar', ...])` to extract a `.tar.bz2`

### Which operating system are you running Bazel on?

Windows 10/Windows 2022

### What is the output of `bazel info release`?

bazel info release
INFO: Invocation ID: b038da1e-5cf1-4a9f-87d0-ccfd89393135
release 6.2.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?

_No response_

### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

_No response_

### Have you found anything relevant by searching the web?

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw#parameters

### Any other information, logs, or outputs that you want to share?

_No response_

Reproduce the Windows 10/Windows Server 2022 case with rctx.execute(['tar', ...]) on a .tar.bz2 archive, then compare it with rctx.execute(rctx.which("tar")). Read the CreateProcessW PATH behavior cited in the report and determine how command resolution currently behaves; done means the extraction no longer hangs and the behavior is covered by an appropriate regression check.

Written by the indexing model from the issue text.