vis-language-python — a managed Python REPL exposed through the generic
language facade (repl / repl_eval / repl_stop). Activates
only when the workspace looks like a Python project. The REPL is a subprocess
on a project-aware interpreter (uv / poetry / .venv / python3), registered as
a session resource so it shows in ctx + the footer and is stoppable by id.

Resolve WHICH Python launches a REPL, mirroring how the Clojure pack picks
deps.edn / lein / bb. Prefers a project-managed env so the REPL sees the
project's dependencies — not the bare system interpreter.

A MANAGED Python REPL: a persistent interpreter subprocess running a tiny
line-framed eval server — one JSON request per line in, one JSON response per
line out. Globals persist across evals (real REPL state). One process per dir;
the `Process` handle is cached so teardown is clean.

`format_code` / `lint_code` for Python, backed by ruff (com.blockether/ruff).

ruff runs IN-PROCESS: the Rust ruff_python_formatter / ruff_linter crates are
linked as a cdylib and called over the FFM API. There is no `ruff` binary to
install, no subprocess, no virtualenv, and no PATH lookup — the same code path
works from the native image. Configuration is RUFF'S OWN discovery: for every
source, ruff walks up from the file to the nearest `.ruff.toml` / `ruff.toml` /
`pyproject.toml` with a `[tool.ruff]` table and honours it whole — `extend`,
`per-file-ignores`, `target-version`, formatter options — so a run here and a
`ruff` CLI run agree. With no config anywhere the tool still runs on ruff's
defaults and SAYS SO in a `hint`.

Both handlers accept the SAME argument shapes as the Clojure pack:
a code string, {"code"}, {"path"}, {"paths"}, or nothing (whole project).