kernel: resolve the pyfun binary from the kernel`s own env before PATH

Caught by verifying the released v0.0.8 wheel in a clean venv: with a
stale global pyfun (pre-kernel-engine) shadowing the venv`s on PATH,
shutil.which handed the kernel a binary without the protocol. Discovery
order is now PYFUN_BIN -> sys.exec_prefix Scripts/bin -> PATH. Verified
against the released wheel with the fix applied: install.py kernelspec
+ full cell session all pass; ROADMAP verification gaps updated.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SoP7DMAgjNCihZHsdBagYr

Author: simontreanor

ROADMAP.md

@@ -51,12 +51,15 @@ dev machine. Close each by running the listed check once; delete its line when i
 - **Tree-sitter rendering**: captures are validated with `tree-sitter query`, but no themed
   highlight render (`tree-sitter highlight` needs a configured theme) and no `test/corpus/` golden
   trees — the gate is the zero-ERROR parse sweep + compiler-validated `test/stress.pyfun`.
-- **Jupyter kernel**: verified end-to-end via `jupyter_client` on Windows/CPython 3.14, but (a)
-  `python -m pyfun_kernel.install` itself has never run (the e2e wrote its own dev kernelspec), (b)
-  no real JupyterLab/Notebook UI session yet, (c) the engine-death replay path in `kernel.py` is
-  code-reviewed only, (d) KeyboardInterrupt during a long cell untested, (e) macOS/Linux untested.
-  The pip-installed `[jupyter]` extra + `install.py` path should be checked against the first wheel
-  that ships the kernel (v0.0.8).
+- **Jupyter kernel**: verified end-to-end via `jupyter_client` on Windows/CPython 3.14 — including,
+  against the released v0.0.8 wheel in a clean venv: the `[jupyter]` extra, `python -m
+  pyfun_kernel.install --sys-prefix`, and a full cell session on the installed kernelspec. Still
+  open: (a) no real JupyterLab/Notebook UI session yet, (b) the engine-death replay path in
+  `kernel.py` is code-reviewed only, (c) KeyboardInterrupt during a long cell untested, (d)
+  macOS/Linux untested. Known issue in the shipped 0.0.8 wheel (fixed in main, ships next tag):
+  `kernel.py` resolved the `pyfun` binary via PATH before the kernel's own environment, so a stale
+  global `pyfun` older than the kernel-engine protocol would break the kernel; discovery order is
+  now PYFUN_BIN → same-env Scripts/bin → PATH.
 
 ## Non-goals (decided against — with the reason, so they're not re-litigated)
 

python/pyfun_kernel/kernel.py

@@ -49,10 +49,21 @@ def __init__(self):
 
     @staticmethod
     def _binary():
-        exe = os.environ.get("PYFUN_BIN") or shutil.which("pyfun")
+        exe = os.environ.get("PYFUN_BIN")
+        if exe:
+            return exe
+        # Prefer the binary installed alongside this interpreter (the wheel
+        # puts it in Scripts/bin of the same environment) — a stale `pyfun`
+        # elsewhere on PATH may predate the kernel-engine protocol.
+        scripts = "Scripts" if os.name == "nt" else "bin"
+        suffix = ".exe" if os.name == "nt" else ""
+        local = os.path.join(sys.exec_prefix, scripts, "pyfun" + suffix)
+        if os.path.exists(local):
+            return local
+        exe = shutil.which("pyfun")
         if not exe:
             raise EngineError(
-                "cannot find the `pyfun` binary on PATH "
+                "cannot find the `pyfun` binary in this environment or on PATH "
                 "(pip install pyfun-lang); set PYFUN_BIN to override"
             )
         return exe