bazel info with --disk_cache or --remote_cache partially invalidates analysis cache

### Description of the bug:

Running `bazel info` causes partial invalidation of the analysis cache when either `--disk_cache` or `--remote_cache` is set via `.bazelrc.` More specifically, it results in many new Actions being created (but not necessarily executed).

This behavior is unexpected because:
- No build inputs change
- No build options relevant to the target configuration change
- `bazel info` should be read-only with respect to analysis state

Additionally:
- The issue only occurs for one of the `bazel info bazel-bin | bazel-genfiles | bazel-testlogs` (config-dependent info keys)

For a very large build, it causes the creation of 1M+ new actions, and processing them takes several minutes.

### Which category does this issue belong to?

Core

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

Minimal repo https://github.com/opikalo/bazelbuild-29176-reproducer/tree/main

Running `bazel info` after a full build will result in new actions created for consecutive warm build.

Minimal Repro
`.bazelrc`
```
build --disk_cache=/tmp/bazel/disk-cache
common --build_event_json_file=/tmp/bep.json
```
`MODULE.bazel`
```
module(
name = "minimal_bazel",
version = "0.1.0",
)

bazel_dep(name = "rules_python", version = "1.5.3")
```
`BUILD.bazel`
```
load("@rules_python//python:py_test.bzl", "py_test")

py_test(
name = "py_smoke_test",
srcs = ["py_smoke_test.py"],
main = "py_smoke_test.py",
)
```
`py_smoke_test.py`
```
def test_basic_math():
assert 2 + 2 == 4

if __name__ == "__main__":
test_basic_math()
```

Helper utility to look at the build event protocol:
`stats.sh`
```
jq -r '
select(.buildMetrics? and .buildMetrics.actionSummary?) |
.buildMetrics.actionSummary |
{
actionsCreated,
actionsExecuted
}
' /tmp/bep.json
```

Normal case, build -> warm build -> actionsCreated = null
```
> bazel clean --expunge && bazel build ... && bazel build ... && ./stats.sh
```
gets you
```
{
"actionsCreated": null,
"actionsExecuted": "1"
}
```
Reproduce the issue:
```
> bazel clean --expunge && bazel build ... && bazel info && bazel build ... && ./stats.sh
```
Results in new actions created.
```
{
"actionsCreated": "43",
"actionsExecuted": "1"
}
```

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

Ubuntu 20.04.6 LTS

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

release 9.0.1

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

Was able to repoduce on
- 9..0.1
- 9.0.0
- 8.6.0
- 8.0.0 - consecutive rerun of the command appears to get no new actions

The issue is not present in:
- 7.7.1 - consecutive rerun of the command appears to get no new actions
- 7.2.1 - clean on first try

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

Several related issues:
https://github.com/bazelbuild/bazel/issues/22360
Seems related: but I have a very tiny reproducer for this.

https://github.com/bazelbuild/bazel/issues/24554
Might be related because of the changes in relevant area

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

Removing `--disk_cache` or `--remote_cache` → issue disappears
Other RemoteOptions (e.g., `--remote_cache_async`, `--remote_max_connections`) do not reproduce the issue
bazel info for any other non bazel keys (without bazel-*) does not reproduce the issue
Absolute paths vs ~ expansion for disk cache location → no difference
Running `bazel query ...` after the `bazel info` issue appears restores expected behavior

Suspected Root Cause

Based on source inspection:
`bazel info bazel-bin` requires a configuration and goes through:
`InfoCommand.exec`
`setBaselineConfiguration(...)`
`getConfiguration(...)`
`setBaselineConfiguration(...)` injects:
`BASELINE_CONFIGURATION`
`BASELINE_EXEC_CONFIGURATION`
These are PrecomputedValues in Skyframe
If the injected `BuildOptions` differ (e.g., due to presence of --disk_cache / --remote_cache), this can invalidate reverse dependencies

Relevant code paths:

`InfoCommand` → `configurationSupplier` → `setBaselineConfiguration`
`SkyframeExecutor.setBaselineConfiguration`
`BaselineOptionsFunction`
`PrecomputedValue`

Run the minimal reproducer with the listed Bazel versions and compare the build-event action counts before and after bazel info. Start by tracing InfoCommand.exec through configurationSupplier and SkyframeExecutor.setBaselineConfiguration, then inspect BaselineOptionsFunction and the BASELINE_CONFIGURATION values. Done means config-dependent bazel info no longer creates unnecessary actions when disk or remote caching is configured, while the warm build remains unchanged.

Written by the indexing model from the issue text.