Targets not loaded from module dependencies

### Description of the bug:

So, I think there are a couple of issues going on with what I'm experiencing, some of which may require bugs in other repos (such as `rules_jvm_external` and/or `contrib/rules_jvm`), but it seems like at least part of the problem here has to do with Bazel's external dependency resolution.

The situation is I'm using both `contrib_rules_jvm` and `rules_jvm_external` and some of the dependencies relied upon by my maven dependencies are depended on as Bazel modules by `contrib_rules_jvm`. `rules_jvm_external` somehow knows that these repositories provide stuff needed by my maven dependencies and aliases to them. This shouldn't be a problem.

The problem, and the reason I'm posting a bug here instead of in one of those other repositories, is that the error message complains about not being able to find a target in a particular `BUILD` file, but the target absolutely, 100% exists in that `BUILD` file. This seems like a Bazel problem.

I get this error:

```
ERROR: /private/var/tmp/_bazel_tr185153/137ff55c66a4db7e6839fa2a6b65316a/external/googleapis+/google/rpc/BUILD.bazel: no such target '@@googleapis+//google/rpc:rpc_java_proto': target 'rpc_java_proto' not declared in package 'google/rpc' defined by /private/var/tmp/_bazel_tr185153/137ff55c66a4db7e6839fa2a6b65316a/external/googleapis+/google/rpc/BUILD.bazel
ERROR: /private/var/tmp/_bazel_tr185153/137ff55c66a4db7e6839fa2a6b65316a/external/grpc-java+/xds/BUILD.bazel:16:13: no such target '@@googleapis+//google/rpc:rpc_java_proto': target 'rpc_java_proto' not declared in package 'google/rpc' defined by /private/var/tmp/_bazel_tr185153/137ff55c66a4db7e6839fa2a6b65316a/external/googleapis+/google/rpc/BUILD.bazel and referenced by '@@grpc-java+//xds:xds'
```

I copied the path `/private/var/tmp/_bazel_tr185153/137ff55c66a4db7e6839fa2a6b65316a/external/googleapis+/google/rpc/BUILD.bazel`, opened it in vim, and sure enough I see:

```
java_proto_library(
name = "rpc_java_proto",
deps = [
":code_proto",
":error_details_proto",
":status_proto",
],
)
```

Which is a target of the name it's looking for.

When I query that package, I get only the first 3 results defined in the `BUILD.bazel` file, even though there are many:

```
❯ bazel query @@googleapis+//google/rpc:all
@@googleapis+//google/rpc:code_proto
@@googleapis+//google/rpc:error_details_proto
@@googleapis+//google/rpc:status_proto
```

Not sure if it's relevant, but I did note that the only results of query just happen to be identical to the deps of the failing target.

On another note, when I don't include `contrib_rules_jvm` as a Bzlmod dependency, everything works just fine and my external maven deps depend on a target generated by `rules_jvm_external` instead of the ones in the repo created by `contrib_rules_jvm`. When I include `contrib_rules_jvm`, these targets are still generated prefixed with `original_`. For a workaround, is there a way, to your knowledge, to override references to `"@@grpc-java+//xds:xds_maven"` (the one from `contrib_rules_jvm`) with references to `":original_io_grpc_grpc_xds"` (the one from `rules_jvm_external`).

### Which category does this issue belong to?

External Dependency

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

Create a Bazel project with the following `MODULE.bazel`:

```
bazel_dep(name = "contrib_rules_jvm", version = "0.28.0")
```

Then run:

```
bazel query @@googleapis+//google/rpc:all --output=build
```

Grab the path to the `BUILD.bazel` file, and inspect it. Comparing it to the output of `query` you can see that `BUILD.bazel` contains many more targets than the `query` output.

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

MacOS Sonoma 14.7.1

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

release 8.1.1

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

N/A

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

```text
I assume this is for if I built Bazel myself? I didn't.
```

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

I have tried and I have not found anything.

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

_No response_