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.

run_pytest.sh

@@ -114,6 +114,12 @@ preflight "FlagGems directory exists: $FLAGGEMS_DIR" test -d "$FLAGGEMS_DIR"
 # The node's file half; the ::test_<fn> half is left to pytest, which reports a
 # missing function clearly ("not found: ...") while a missing FILE does not.
 preflight "benchmark file exists: ${TEST_FILE%%::*}" test -f "${TEST_FILE%%::*}"
+# The interpreter, not just the paths. triton and flag_gems normally come from a
+# PYTHONPATH pointing at a compiler build and a source checkout, so a shell that
+# merely reaches the right files can still be the wrong Python. Without this the
+# failure surfaces per cell as `pytest exit 4` from a conftest ImportError, and a
+# multi-round campaign burns every cell before anyone reads a log.
+preflight "interpreter imports triton + flag_gems ($(command -v python))"   sh -c 'python -c "import triton, flag_gems" 2>/dev/null'
 if [[ -n "$SHAPE_FILE" ]]; then
   preflight "shape file exists: $SHAPE_FILE" test -f "$SHAPE_FILE"
 fi