windows: "failed to create installation symlink" when output_base is in a docker volume

### Description of the bug:

My CI builds are executed on Windows within windows containers. I want to share a cache between all this containers to reduce build times.

When I run a container with a volume mounted on my drive, Bazel returns this error :
```
Extracting Bazel installation...
ERROR: SymlinkDirectories(C:/Users/ContainerAdministrator/_bazel_ContainerAdministrator/install/c9ea1a9caee100e72d651d25da00df4d, c:\bazel\install): CreateJunction:
FATAL: failed to create installation symlink 'c:\bazel\install': success
```

The install directory is created so I do not understand this error. Manually I can create both a junction or a symlink without error.

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

1. Run a windows container with a mounted directory
`docker run -it -v C:\cache:C:\bazel mcr.microsoft.com/windows/server:ltsc2022`
2. Run bazel with it's output_base within cache directory :
```
cd my_bazel_repo
bazel --output_base=C:\bazel build //sometarget
```

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

Windows 10 Pro / Windows Server 2022 Standard Edition

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

release 5.4.0

### 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_

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

_No response_

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

I've noticed that this bug does not occur if the host OS is Windows Server 20XX Datacenter Edition.

I haven't found any info on that but to me Bazel should not return this error since the install directory is created.

Start by reproducing the failure with the provided Windows container and `--output_base=C:\bazel`, then inspect Bazel's Windows installation symlink handling. Done means a build succeeds when `output_base` is inside a Docker-mounted volume, or the issue is documented with the platform limitation and a clear diagnostic.

Written by the indexing model from the issue text.