Allow exporting transitive module dependencies

### Description of the feature request:

# Need to have

I am in a situation where I maintain many Bazel modules for a robotics ecosystem. Periodically I want to cut a release that is essentially a snapshot of these Bazel modules at specific versions. I don't want the user to have to think about the version of each module within the release. What would be nice is for them to bring in a single "release" module with pinned deps, and then allow the user to export select transitive dependencies (via the module rule `export_repo`) into their workspace:

```py
# MODULE.bazel for the user project
module(
name = "my_example_robotics_project",
version = "0.0.0"
)

bazel_dep(name = "ros", version = "rolling.2026-01-21")
export_repo(module_name = "ros", repo_name = "sensor_msgs") # sensor_msgs at version rolling.5.9.1-1
export_repo(module_name = "ros", repo_name = "rclcpp") # rclcpp at version rolling.30.1.4-1
```

After doing, this user should be able to use any target, eg. `@sensor_msgs//msg:Imu`, as if they had imported it themselves with `bazel_dep(name = "sensor_msgs", version = "rolling.5.9.1-1")`. This is because the the `MODULE.bazel` file for `ros` imports these versions, which are exported by `export_repo`:

```py
# MODULE.bazel for the "release" module
module(
name = "ros",
version = "rolling.2026-01-21"
)
bazel_dep(name = "rclcpp", version = "rolling.30.1.4-1")
bazel_dep(name = "sensor_msgs", version = "rolling.5.9.1-1")
```

# Nice to have

It would also be incredibly useful for this to work seamlessly with `multiple_version_override`, so that the user can include modules from two different releases. This is so that we can write application code that is able to support multiple versions of the same underlying message. For example:

```py
module(
name = "my_example_robotics_project",
version = "0.0.1"
)

bazel_dep(name = "ros", version = "jazzy.2026-01-28", repo_name = "ros_jazzy")
bazel_dep(name = "ros", version = "kilted.2026-01-22", repo_name = "ros_kilted")

multiple_version_override(
module_name = "ros",
versions = [
"jazzy.2026-01-28",
"kilted.2026-01-22"
],
)

export_repo(
module_name = "ros_jazzy",
repo_name = "sensor_msgs",
export_name = "sensor_msgs_jazzy"
)

export_repo(
module_name = "ros_kilted",
repo_name = "sensor_msgs",
export_name = "sensor_msgs_kilted"
)
```

Now the user can reference the targets `@sensor_msgs_jazzy//msg:Imu` and `@sensor_msgs_kilted//msg:Imu` to support different versions of the same message within application code.

### Which category does this issue belong to?

Core

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

Avoid having the user download and maintain `MODULE.bazel` templates that look like this...

```py
module(
name = "ros",
version = "rolling.2026-01-21",
)

bazel_dep(name = "action_msgs", version = "rolling.2.4.1")
bazel_dep(name = "ament_clang_format", version = "rolling.0.20.1")
bazel_dep(name = "ament_clang_tidy", version = "rolling.0.20.1")
bazel_dep(name = "ament_cmake_auto", version = "rolling.2.8.4")
bazel_dep(name = "ament_cmake_clang_format", version = "rolling.0.20.1")
bazel_dep(name = "ament_cmake_clang_tidy", version = "rolling.0.20.1")
bazel_dep(name = "ament_cmake_copyright", version = "rolling.0.20.1")
bazel_dep(name = "ament_cmake_core", version = "rolling.2.8.4")
...
azel_dep(name = "tracetools", version = "rolling.8.8.0")
bazel_dep(name = "trajectory_msgs", version = "rolling.5.8.1")
bazel_dep(name = "type_description_interfaces", version = "rolling.2.4.1")
bazel_dep(name = "unique_identifier_msgs", version = "rolling.2.8.0")
bazel_dep(name = "visualization_msgs", version = "rolling.5.8.1")
bazel_dep(name = "zenoh_security_tools", version = "rolling.0.8.1")
```

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

Linux, Mac, Windows

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

release 9.0.0

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

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

_No response_

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

_No response_

Start with the MODULE.bazel examples and the existing module-rule handling for export_repo and multiple_version_override. Define and verify the behavior for exporting selected transitive repositories, including renamed exports and multiple module versions, across Linux, macOS, and Windows; done means the documented target references resolve at the pinned versions.

Written by the indexing model from the issue text.