docs: py-spy 0.4.1 lacks Python 3.14 support; wrapper aborts early

Root cause of 'No python processes found in process <pid>': py-spy needs
per-release ABI knowledge and 0.4.1 (latest PyPI) predates 3.14. Wrapper
now detects the interpreter and points users at pyinstrument/memray/cProfile.

tests/perf/README.md

@@ -4,6 +4,13 @@ Five complementary lenses. Pick whichever answers the question you have.
 
 ## 1. Whole-process sampling — py-spy
 
+> **Note:** py-spy 0.4.1 (latest on PyPI as of 2026-04) does **not** yet support
+> Python 3.14, which DECNET currently runs on. Attaching fails with
+> *"No python processes found in process <pid>"* even when uvicorn is clearly
+> running. Use lenses 2–5 until upstream ships 3.14 support
+> (track https://github.com/benfred/py-spy/releases). The wrapper script aborts
+> with a clear message when it detects 3.14+.
+
 Attach to a running API and record a flamegraph for 30s. Requires `sudo`
 (Linux ptrace scope).
 
@@ -12,7 +19,7 @@ Attach to a running API and record a flamegraph for 30s. Requires `sudo`
 sudo py-spy record -o profile.svg -p <PID> -d 30 --subprocesses
 ```
 
-If py-spy "doesn't work", it is almost always one of:
+Other common failure modes (when py-spy *does* support your Python):
 - Attached to the Typer CLI PID, not the uvicorn worker PID (use `pgrep -f 'uvicorn decnet.web.api'`).
 - `kernel.yama.ptrace_scope=1` — run with `sudo` or `sudo sysctl kernel.yama.ptrace_scope=0`.
 - The API isn't actually running (a `--dry-run` deploy starts nothing).