A python3 that exists and is not an interpreter said the engine was broken

[chongjiazhen]

tests/run.sh guards its python3-backed checks with command -v python3, which
was written for an absent interpreter. On Windows the name on PATH is usually
the Microsoft Store App Execution Alias: a zero-byte reparse point
(AppInstallerPythonRedirector.exe) that command -v finds happily, that exits
49, and that prints an advert for the Store instead of running anything.

Present, and not an interpreter. So the guard never fires and all 39 call
sites run against it.

This is #42's finding arriving through the same door wearing the opposite
disguise, and run_uv already carries the mental model one tool over: a uv that
is present and cannot work does not fail, it hangs.

What it looks like on a stock Windows dev box

Windows 10, MinGW-w64 GCC 15.2, Python 3.13 installed and working under its own
name, make CC=gcc check:

7 passed, 7 failed, 16 skipped

The failures read range server did not start, convert.py resume,
convert.py chat.json, serve suite. That is the engine called broken when
what is wrong is a shim on PATH, which is the one thing line 10 says this suite
must never do.

The 16 skips are the same cause one step earlier: make_test_container.py is
python3 too, so the synthetic container never built, SYNTHETIC stayed 0, and
every check needing a container skipped for want of one. That is why this is not
a 7-check fix.

The trace-simulator guard is the one worth calling out: it takes the
command -v branch with a real container present, the simulator then returns
nothing, and the suite reports trace simulator disagrees with the engine
against an interpreter that never ran. It moves to PY_MISS with the rest.

The change

Probe by running it rather than by looking it up. Windows installs the
versionless python, and py besides, so a working interpreter is normally
sitting right there under another name: shim the first one that answers into
PATH. Placed ahead of the synthetic-container build, so that build gets it too,
and it reaches the subprocesses (check_budget.sh, the serve suite) without
editing either or touching the 39 call sites.

If nothing answers under any name, PY_MISS carries the reason and the checks
SKIP loudly, which is what the command -v guard always meant to do.

Same box, after:

44 passed, 0 failed, 13 skipped

Verification

Three states, all on the box described above:

state	result
working python3 on PATH (manual shim, as a baseline)	44 passed, 0 failed, 13 skipped
this patch alone, Store alias on PATH	44 passed, 0 failed, 13 skipped
all three names shimmed to exit 49, i.e. no interpreter anywhere	7 passed, 0 failed, 24 skipped, exit 0

The third row is the one that matters for the guard: the eight checks skip with
no working python3 (the name on PATH is not an interpreter) rather than
failing.

The first two rows agreeing is the point of the second: the patch reaches the
same state the environment fix would, so nothing is being papered over.

Not in this diff

Makefile, tools/fetch_weights.sh and tools/pipeline.sh carry 13 more bare
python3 call sites with the same exposure. They are release and fetch tooling
rather than the suite, and PATH set inside run.sh does not reach a recipe that
make runs itself, so they want a separate decision about whether the
resolution belongs in the Makefile. Happy to do that as a follow-up if you want
it, in whichever shape you prefer.

Also worth knowing for anyone cloning on Windows: with git's default
core.autocrlf=true the whole worktree smudges to CRLF, and a patch then diffs
as a whole-file rewrite. Set core.autocrlf=false before cloning. Same family
as #47, one layer out, and not something a code change here can fix.

---

Assisted by AI.

[chongjiazhen]

Context I should have put in the description: this repo has had two thorough
native-Windows audits already, #3 and #36, and neither could have hit this.
Both ran under MSYS2 (MINGW64 and UCRT64), where python3 is a real Windows
CPython. The guard is only wrong where python3 resolves to the Store alias,
which is stock Windows plus Git-Bash rather than an MSYS2 subsystem. So this is
a third environment rather than something those reports missed, and their gap
lists and this one do not intersect: #3's four are cc/SOEXT/test_kda.exe/
sysconf, #36's five are resource, .shards CRLF, oracle provenance,
diskbench and WASTE_MLOCK.

It is the same kind as #36's gap 1, though, which you accepted in exactly
these terms: a check that reports FAIL where it means "could not measure", when
run.sh's header says a missing prerequisite says SKIP loudly and is never
treated as a pass. Gap 1 gets there via import resource; this gets there via
a name on PATH that is not an interpreter.

Worth knowing for whoever merges: #48 also touches tests/run.sh, at line 813
and below. This PR's hunks are the top of the file plus the four guards, so the
two do not overlap textually.