Windows: Batch files cannot be path shortened enough

### Description of the bug:

Performing a `bazel test` with a target whose executable is a batch file with a path above >256 characters will fail when either 8dot3name support is unavailable, or when the path cannot be shortened enough. While https://github.com/bazelbuild/bazel/issues/19710 now ensures that .exe files are handled correctly (by prepending `\\?\`), Batch files are explicitly left out.

### Which category does this issue belong to?

Core, Local Execution

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

Create a batch file with an extremely long (>256 character) path and wire up a bazel test to it, invoking it such that the test runner (tw.exe) runs it. You should also disable 8dot3name support on your file system during the test as it's the easiest way to ensure the path can never be shortened. `fsutil 8dot3name set 1` will disable path shortening.

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

Windows 11

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

release 8.6.0

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

This is a development version that includes a backport of https://github.com/bazelbuild/bazel/pull/29921 to try and mitigate long paths in our .ci infrastructure.

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

```text

```

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

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

_No response_

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

Interestingly I have a fix for this on our local bazel fork that just passes the batch file to `CreateProcessW` and it works just fine. Providing that you also add the Manifest as `Nwatkiss` points out in this comment from a previous attempt at longpath fixing [here](https://github.com/bazelbuild/bazel/pull/22532#issuecomment-3368991978). It's important to note that you *cannot* pass the batch file with a `\\?\` prefix as `cmd.exe` apparently doesn't know what to do with it.

According to `CreateProcessW` [documentation](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw), any batch file being passed MUST "set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.".

I can raise a PR with a possible fix for this, but I'm unsure about tying functionality to undocumented support in Windows.

Start at Bazel's Windows local-execution path that launches tw.exe and trace its CreateProcessW handling for batch files. Reproduce the failure with a path over 256 characters and 8dot3name disabled, then verify that batch tests launch successfully without passing a \\?\ prefix and that the required cmd.exe invocation and manifest behavior are covered.

Written by the indexing model from the issue text.