java_binary `deploy_env` behaves differently for `bazel run` vs. `--singlejar`

### Description of the bug:

It looks like `deploy_env` is working different depending on the `java_binary` is executed with `bazel run //target` vs. directly with `bazel-bin/target/target --singlejar`.

The `target_deploy.jar` is missing classes which are present in `CLASSPATH`.

### Which category does this issue belong to?

Java Rules

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

Assuming a deploy filter and a library like this:

```Starlark
_unwanted_log_deps = [
"@org_slf4j_slf4j_simple",
"@ch_qos_reload4j_reload4j",
"@commons_logging_commons_logging",
"@org_apache_logging_log4j_log4j_api",
"@org_apache_logging_log4j_log4j_core",
]

java_binary(
name = "deploy_filter_jul",
main_class = "does.not.exists.Class",
runtime_deps = [
"@ch_qos_logback_logback_classic",
"@ch_qos_logback_logback_core",
] + _unwanted_log_deps,
)

java_library(
name = "starterkit_jul",
exports = [
...
"@info_picocli_picocli",
"@org_slf4j_jcl_over_slf4j",
"@org_slf4j_log4j_over_slf4j",
"@org_slf4j_slf4j_api",
],
runtime_deps = [
...
":jul",
],
)

java_library(
name = "jul",
...
deps = [
...
"@org_slf4j_slf4j_api",
"@org_slf4j_slf4j_jdk14",
],
)
```

Then a consumer like this:

```Starlark
java_binary(
name = "target,
data = [
...
],
deploy_env = [
"//:deploy_filter_jul",
],
...
visibility = ["//visibility:public"],
runtime_deps = [
":somelib",
],
)

java_library(
name = "somelib",
...
deps = [
...
"//:starterkit_jul",
],
)
```

Now building the target produces the following:

```Bash
> cat bazel-bin/target/target | grep slf4j_slf4j
CLASSPATH="....:${RUNPATH}../org_slf4j_slf4j_api/slf4j-api-2.0.7.jar:...:${RUNPATH}../org_slf4j_slf4j_jdk14/slf4j-jdk14-2.0.7.jar:...

> jar -tf bazel-bin/tools/build/bazel/rules/plsql/db-all_deploy.jar | grep "org/slf4j/"
org/slf4j/jul/
org/slf4j/jul/JDK14LoggerAdapter$1.class
org/slf4j/jul/JDK14LoggerAdapter.class
org/slf4j/jul/JDK14LoggerFactory.class
org/slf4j/jul/JULServiceProvider.class
```

So the `deploy.jar` does not contain SLF4J API but SLF4J JUL implementation. But the launcher script contains *both* on its classpath.

A possible explanation is that the deploy filter is incorrectly excluding transitives.

```Bash
> bazel query "somepath( //:deploy_filter_jul, @org_slf4j_slf4j_api//:org_slf4j_slf4j_api )"
//:deploy_filter_jul
@ch_qos_logback_logback_classic//:ch_qos_logback_logback_classic
@org_slf4j_slf4j_api//:org_slf4j_slf4j_api
```

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

_No response_

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

release 7.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 HEAD` ?

_No response_

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

Slack discussion: https://bazelbuild.slack.com/archives/CDCE4DFAP/p1721804811250749

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

_No response_

Reproduce the example with Bazel 7.2.1 using java_binary, deploy_env, bazel run, and the generated --singlejar target; inspect the launcher CLASSPATH and target_deploy.jar, then use the shown bazel query to compare dependencies. Done means the deploy jar and bazel run behavior consistently include the expected SLF4J classes, or the discrepancy is explained and covered by a regression test.

Written by the indexing model from the issue text.