The build and the fetch tooling reach for python3 by name too

[chongjiazhen]

Follow-up to #51, offered there and kept separate so each is reviewable on its
own. Same finding one layer out: on Windows python3 on PATH is usually the
Microsoft Store App Execution Alias, a zero-byte reparse point that exists,
exits 49, and prints an advert for the Store instead of running anything.

tests/run.sh can shim PATH for its own call sites. That does not reach a
recipe make runs itself, nor either tools script when run directly, so 11
call sites are still exposed:

file	sites
Makefile	3: serve-check, fuzz, fuzz-asan
tools/fetch_weights.sh	4
tools/pipeline.sh	4

pipeline.sh is the one that misdiagnoses rather than merely failing. Its first
two probes end 2>/dev/null || echo 0, so an interpreter that is not one yields
0 and the script dies with download (no index at $SRC), naming a missing
index that is present and perfectly readable.

The change

The Makefile resolves $(PY) by running a candidate; the two scripts resolve
$PY the same way, and pipeline.sh exports it so the fetch_weights.sh it
drives inherits the answer instead of resolving once per stage.

Nothing skips here, deliberately. If no candidate answers, PY stays python3
and the recipe or script fails loudly at first use. That is the right behaviour
for a build target and for a 1.4 TB download: unlike the suite there is nothing
to skip, and a run that cannot read its own index must stop rather than carry
on.

fetch_weights.sh already knew it runs on Windows, at the tr -d '\r' comment
citing #36 gap 2. This is the same environment, one assumption earlier.

$(PY) is recursive rather than := deliberately. Immediate assignment runs
the probe on every make invocation, make clean and a no-op build included,
and where python3 is the alias the first spawn is the alias itself: measured
196 ms added per invocation, which nearly triples a no-op make. Lazy, it
runs only when a Python recipe expands it. The fallback sits inside the shell
for the same reason, since an ifeq on $(PY) would force the expansion at
parse time and undo it.

Verification

Windows 10, MinGW-w64 GCC 15.2, Python 3.13 working under its own name.
make -p reports PY := python.

make serve-check          -> OK (skipped=3)                              exit 0
make fuzz FUZZ_RUNS=20    -> 20 cases: 12 rejected, 8 still loaded,
                             0 crashed, 0 hung / FUZZ OK                 exit 0
no-op `make` x3           -> 0.664 s  (main: 0.678 s; with `:=` 1.277 s)
all three names exit 49   -> serve-check dies Error 49, loudly, no skip

The two tools scripts are not run end to end here, because that needs the
full source weights. They carry bash -n, review, and a three-state check of
the added resolver:

state	result
Store alias first on PATH	PY=python, runs 3.13.5
all three names shimmed to exit 49	PY=python3, fails loudly at first use (49)
PY already set in the environment	respected, no re-resolution

Happy to fold this into #51 instead, or to change the shape: a single shared
resolver sourced by both scripts would also work, I kept them self-contained to
match how they read today.

---

Assisted by AI.