ctx.executable.X passed to subrule_ctx.actions.run_shell(tools=) doesn't have runfiles attached

### Description of the bug:

If you pass `ctx.executable.X` from the main rule to the `tools` argument of `subrule_ctx.actions.run_shell()` in a subrule, the runfiles aren't attached.

This is not the case when you pass `ctx.executable.X` to `tools` of `ctx.actions.run_shell()` in the main rule.

### Which category does this issue belong to?

Rules API

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

myrule.bzl

```starlark
def _my_subrule_impl(subrule_ctx, foo_executable):
out = subrule_ctx.actions.declare_file(subrule_ctx.label.name)
subrule_ctx.actions.run_shell(
tools = [foo_executable],
outputs = [out],
command = foo_executable.path + " > " + out.path,
)
return DefaultInfo(files = depset([out]))

_my_subrule = subrule(
implementation = _my_subrule_impl,
)

def _myrule_impl(ctx):
return _my_subrule(foo_executable = ctx.executable.foo)

myrule = rule(
implementation = _myrule_impl,
attrs = {
"foo": attr.label(
default = "//:foo",
executable = True,
cfg = "exec",
),
},
subrules = [_my_subrule],
)
```

BUILD.bazel
```starlark
load("@rules_python//python:defs.bzl", "py_binary")
load(":myrule.bzl", "myrule")

py_binary(
name = "foo",
srcs = ["foo.py"],
)

myrule(
name = "mytarget",
)
```

MODULE.bazel
```starlark
bazel_dep(name = "rules_python", version = "1.5.1")
```

foo.py is an empty file.

With this set up:

```
$ bazel build :mytarget
INFO: Analyzed target //:mytarget (1 packages loaded, 3 targets configured).
ERROR: /android/tmp/BUILD.bazel:9:7: Action mytarget failed: (Exit 1): bash failed: error executing Action command (from target //:mytarget) /bin/bash -c 'bazel-out/k8-opt-exec-ST-d57f47055a04/bin/foo > bazel-out/k8-fastbuild/bin/mytarget'

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
Traceback (most recent call last):
File "/.cache/bazel/_bazel_elsk/025625c2cec74abb244468308f82b41b/sandbox/linux-sandbox/1/execroot/_main/bazel-out/k8-opt-exec-ST-d57f47055a04/bin/foo", line 622, in
Main()
File "/.cache/bazel/_bazel_elsk/025625c2cec74abb244468308f82b41b/sandbox/linux-sandbox/1/execroot/_main/bazel-out/k8-opt-exec-ST-d57f47055a04/bin/foo", line 513, in Main
module_space = FindModuleSpace(main_rel_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/.cache/bazel/_bazel_elsk/025625c2cec74abb244468308f82b41b/sandbox/linux-sandbox/1/execroot/_main/bazel-out/k8-opt-exec-ST-d57f47055a04/bin/foo", line 206, in FindModuleSpace
raise AssertionError('Cannot find .runfiles directory for %s' % sys.argv[0])
AssertionError: Cannot find .runfiles directory for bazel-out/k8-opt-exec-ST-d57f47055a04/bin/foo
Target //:mytarget failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.507s, Critical Path: 0.07s
INFO: 3 processes: 3 internal.
```

This is because `bazel-out/k8-opt-exec-ST-d57f47055a04/bin/foo.runfiles` does not exist in the sandbox.

However, if I use `ctx.actions.run_shell()` in the main rule and add `ctx.executable.foo` to tools, it correctly adds the runfiles as stated in https://bazel.build/rules/lib/builtins/actions#run_shell .

**Workaround**: The workaround would be to pass `foo_files_to_run = ctx.attr.foo[DefaultInfo].files_to_run` to the subrule, and use `foo_files_to_run.executable.path` in the command, and pass `foo_files_to_run` to `subrule_ctx.actions.run_shell(tools = )` instead.

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

Linux

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

```

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

_No response_

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

_No response_

Reproduce the failure using myrule.bzl, BUILD.bazel, MODULE.bazel, and the empty foo.py described in the issue, then compare the subrule action with the main-rule action. Trace how subrule_ctx.actions.run_shell() handles the tools argument and runfiles. Done means the minimal build succeeds with ctx.executable.foo passed through the subrule and foo's runfiles are available in the sandbox.

Written by the indexing model from the issue text.