bench: preflight the interpreter, not just the paths

triton normally comes from a PYTHONPATH pointing at a compiler build and
flag_gems from a source checkout, so a shell that reaches every correct path
can still be the wrong Python. run_pytest.sh checked that the FlagGems
directory and benchmark file exist and then handed the run to pytest, where
the real problem surfaced per cell as `pytest exit 4` from a conftest
ImportError.

A multi-round campaign burns every cell that way before anyone reads a log:
today's noise-calibration run lost 12 measurement cells and 160 load runs to
`ModuleNotFoundError: No module named 'triton'`, each failing in under a
second and each looking, from the outside, like a cell that ran.

The check names the interpreter it used, since which Python is on PATH is the
whole question. Its stderr redirect stays on the child — putting `2>/dev/null`
on the preflight call swallows preflight's own `>&2` message and turns a named
refusal into a bare exit 3.

README.md

@@ -188,6 +188,13 @@ benchmark 目录，注册 `--level`/`--mode` 的 `conftest.py` 就没被加载
 只校验节点的文件那一半；`::test_<fn>` 交给 pytest，函数不存在时它自己会清楚地报
 `not found: ...`。
 
+还校验**解释器**——`python -c "import triton, flag_gems"`。triton 通常来自 PYTHONPATH
+指向的编译器构建产物、flag_gems 来自源码检出，所以一个能摸到全部正确路径的 shell
+仍然可能是错的那个 Python。不查的话，失败以每格一次 `pytest exit 4`（conftest 的
+ImportError）出现，多轮 campaign 会在有人读日志之前把每一格都烧掉——这不是假想，
+2026-09-10 的噪声标定实验就这么废了 12 格加 160 次负载 run。报错里带上
+`$(command -v python)`，因为要看的就是"用的到底是哪个解释器"。
+
 ### 口径核对：出报告前的拒绝
 
 `batch_summary.py --ab` / `--ab-rounds` 在解析任何 latency 之前，先读参与对比的每个