Support incompatible_strict_action_env

As of Bazel 9, `--incompatible_strict_action_env=true` is the default.

Almost everything works with that set, the one exception is Windows in a particular case. That particular case appears to be when the python program is a data dep of another binary, e.g. an sh_binary with a py_binary in data. What happens is the Bazel launcher can't find the python interpreter in runfiles, so falls back to looking for `python.exe` on `PATH`. When strict action env is enabled, the outer PATH isn't inherited, so python.exe can't be found, and thus the launcher fails to execute.

A direct execution of a python program is ok, since the runfiles structure is present enough that the bazel launcher can find the interpreter.

Other than moving away from the Bazel launcher, I don't see a way to solve this. We've wanted to stop using the bazel launcher anyways, so this isn't a big deal, this case just add additional pressure to do so.

Fundamentally, when a binary is running within another binary's runfiles, the logic to find things is a bit more convoluted. We can use RunEnvironmentInfo so that tests auto-inherit PATH, but this only helps tests. binaries-in-binaries or binaries-run-by-actions wouldn't be affected.

There are two workarounds:

* Set `--incompatible_strict_action_env=false` (restore non-strict env behavior, which includes PATH)
* Set `--action_env=PATH` (only inherit PATH for actions)

Start by reproducing the Windows case with Bazel 9 and strict action environment enabled: an sh_binary with a py_binary in data. Read the Bazel launcher’s runfiles and interpreter lookup behavior, then compare it with direct Python execution and the RunEnvironmentInfo approach. Done means the nested binary can locate its Python interpreter without requiring PATH inheritance or the documented workaround.

Written by the indexing model from the issue text.