Remote cache does not respect `HTTPS_PROXY`

### Description of the bug:

Right now, if you want to use a remote cache for Bazel, and you are on a machine that has no non-proxied network access, that machine must expose _both_ a TCP _and_ a Unix domain socket endpoint; the former for dependency downloads, the latter for [`--remote_proxy`](https://bazel.build/reference/command-line-reference#common_options-flag--remote_proxy). This is troublesome. (And fwiw, this is currently the case on Claude Code for the Web, which also runs afoul of a long-standing issue where Bazel does not like HTTPS proxies with credentials—Anthropic, for whatever reason, uses a JWT credential in its `HTTPS_PROXY` setup.)

This ticket tracks reducing the scope of the proxy challenge from "Unix domain socket plus TCP" to either "just Unix domain socket" or "just TCP."

### Which category does this issue belong to?

_No response_

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

Start a new Claude Code for the Web session against any project that uses Bazel and try to build or test anything.

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

Linux

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

release 8.4.2

### 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 HEAD` ?

```text
git@github.com:mrdomino/bazel
b1630eedbe79a7487a79dc4b7f75d27b22e3c0ab
```

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

The Claude Code for the Web environment is bonkers. E.g., they put `*.googleapis.com` in their `no_proxy`, so once you get to the “Bazel remote cache” part of the maze, you’re liable to spend hours trying to figure out why you’re not successfully circumventing that setting before you realize that the entire proxy configuration is just being completely ignored.

Start by locating Bazel's remote cache handling and the code that reads HTTPS_PROXY, then reproduce the issue in a Linux environment like Claude Code for the Web. The issue names no source file or test; done means remote cache access uses the configured proxy and does not require both TCP and Unix socket endpoints.

Written by the indexing model from the issue text.