Supporting querying for `bzlmod`-induced dependencies (for target determination, static analysis, ...)

### Description of the feature request:

I was surprised to find out that there appears to be no simple programmatic way to determine e.g. that a `go_ilbrary` target depends on the repo's `go.mod` file.

I'm filing a feature request as requested from [this Slack thread](https://bazelbuild.slack.com/archives/CA31HN1T3/p1756232949638999) (2025-08-26).

> @arxanas: With bzlmod and rules_go, how can I query in such a way that I'll learn that a given Go target depends on our go.MODULE.bazel and the repo's go.mod? The buildfiles(deps(...)) recommendation in the [Bazel query guide](https://bazel.build/query/language#buildfiles) doesn't seem to produce them.
>
> [...]
>
> @arxanas: [...] go.mod simply doesn't appear in the dependencies for Go targets? That is:
>
> ```console
> $ bazel query 'somepath(//:go.mod, //go/logger)'
> INFO: Empty results
> $ bazel query 'somepath(//go/logger, //:go.mod)'
> INFO: Empty results
> ```
>
> Likewise, bazel query 'buildfiles(deps(//go/logger))' doesn't obviously include go.MODULE.bazel, despite ostensibly depending on it.
>
> [...]
>
> @ted-xie not a go toolchain expert. my high level view of this is that gazelle creates repository rules from the contents of go.mod. the repository rules are sort of in a different plane than the regular root module targets. hence why i said above that determing the full set would be annoying
>
> you can use `bazel mod show_extension
> re's some bash-fu that gets you 70% of the way there:
>
> ```shell
> bazelisk mod show_extension @bazel_gazelle//:extensions.bzl%go_deps | sed -rn 's/\"([^\"]*)\"/\1/p' | sort | uniq`
> ```
>
> [...]
>
> @dzbarsky: But yes you're right that query/aquery only know about deps starting at external repos, they don't have visibility into how those are created, which is what the module extension is essentially doing
>
> @fmeum: The go_deps extension is reproducible and thus doesn't end up in the regular lockfile
>
> With recent versions of Bazel, it will be stored in the lockfile in the output base
>
> It's true that we lack visibility into what repo rules and module extensions do. Part of the problem is that they can do anything really (run arbitrary executables). But we could expose their runtime dependencies in some way
>
> Could you file a feature request for this?

### Which category does this issue belong to?

CLI, External Dependency

### What underlying problem are you trying to solve with this feature?

- Target determination (i.e. determining which targets to rebuild given a code change). Right now, you may have to hardcode some rules like "all Go targets depend on `go.mod`" or "all targets depend on the bzlmod lockfile".
- Static analysis / data-flow analysis. It's not easy to programmatically infer that `go.mod` flows into Go targets.

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

macOS

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

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

```text

```

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

Does not currently seem possible as per [Slack thread](https://bazelbuild.slack.com/archives/CA31HN1T3/p1756232949638999).

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

_No response_

Start by reproducing the `bazel query` examples using `somepath` and `buildfiles(deps(...))`, then compare them with `bazel mod show_extension @bazel_gazelle//:extensions.bzl%go_deps`. Investigate how query represents module-extension and repository-rule inputs. Done should provide a documented, programmatic way to discover those dependencies for target determination and static analysis.

Written by the indexing model from the issue text.