Cannot run native python binary script without C++ toolchain

# 🐞 bug report

### Affected Rule

`py_binary`

### Is this a regression?

Not tested, unlikely.

### Description

A trivial pure-Python `py_binary` appears to require C++ toolchain resolution even though it does not produce any C++ compile or link actions.

In a minimal example, `bazel cquery //:hello_world --toolchain_resolution_debug='.*'` shows that Bazel resolves both:
- `@@bazel_tools//tools/python:toolchain_type`
- `@@bazel_tools//tools/cpp:toolchain_type`

However, `bazel aquery //:hello_world` only shows Python-related actions such as Python bytecode precompilation and bootstrap/template generation. There are no C++ compile or link actions for the target.

This is surprising for Python-only projects. In environments where no C++ toolchain is configured or available, this can cause a trivial `py_binary` to fail analysis even though the target itself does not build native code.

From a user perspective, I would expect a pure `py_binary` with no native extensions and no C/C++ deps to avoid requiring successful C++ toolchain resolution, or at least for the requirement to be documented if it is intentional.

## 🔬 Minimal Reproduction

`MODULE.bazel`
```starlark
module(
name = "bazel_hello_py",
version = "0.1.0",
)

bazel_dep(name = "rules_shell", version = "0.6.1")
bazel_dep(name = "rules_python", version = "1.7.0")
```
`BUILD.bazel`

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

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

`hello_world.py`

```python
print("hello world")
```

```starlark
bazel run //:hello_world --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=<0|1>
bazel cquery //:hello_world --toolchain_resolution_debug='.*'
bazel aquery //:hello_world
```

Observed behavior:

1. `bazel run //:hello_world` succeeds if the `repo_env` is set to `0` but fails on `1`
2. `cquery shows that @@bazel_tools//tools/cpp:toolchain_type` is resolved for the target.
3. `aquery` shows only Python-related actions and no C++ compile/link actions.

This suggests the C++ toolchain resolution is happening even for a pure-Python binary with no actual C++ build work.

## 🔥 Exception or Error

```bash
$ bazel run //:hello_world --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
ERROR: .../external/bazel_tools/src/tools/launcher/BUILD:75:10: While resolving toolchains for target @@bazel_tools//src/tools/launcher:launcher_maker (04bf134): No matching toolchains found for types:
@@bazel_tools//tools/cpp:toolchain_type
To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/cpp:toolchain_type'
For more information on platforms or toolchains see https://bazel.build/concepts/platforms-intro.
ERROR: Analysis of target '//:hello_world' failed; build aborted: Analysis failed
INFO: Elapsed time: 0.107s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target
```

## 🌍 Your Environment

**Operating System:**

  

     Linux (Ubuntu LTS 24.04)

  

**Output of `bazel version`:**

  

    Bazelisk version: v1.29.0 Build label: 9.2.0 Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer Build time: Mon Jul 13 18:15:04 2026 (1783966504) Build timestamp: 1783966504 Build timestamp as int: 1783966504

  

**Rules_python version:**

  

     1.7.0

  

**Anything else relevant?**

Related issues I found while searching:
rules_python #1857 discusses py_binary and C++ toolchain resolution in cross-compilation scenarios.
rules_python #2500 discusses replacing the stage1 bootstrap with a native launcher.

My main question is whether this C++ toolchain resolution for a pure py_binary is intentional.

Start with the minimal MODULE.bazel and BUILD.bazel example, then run the reported bazel run, cquery, and aquery commands with BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN set to 1. Compare the resolved toolchains and actions to determine whether a pure py_binary can avoid C++ toolchain resolution; done means the behavior is fixed or its intentional requirement is documented.

Written by the indexing model from the issue text.