Python deps: smart missing-package hint + switch to .vrf requirements file

Option A: when a {python} cell fails with ModuleNotFoundError/ImportError, the
log now suggests the exact PyPI package to add (with a module->package map, e.g.
cv2 -> opencv-python, sklearn -> scikit-learn), names the Verso requirements
file, and notes it could instead be a local module — so the langmuirthermalstudy
case isn't mistaken for a PyPI package.

Switch the per-project requirements file from requirements.txt to a Verso-
specific requirements.vrf (so it won't be confused with arbitrary .txt files);
QuartoRunner now looks for requirements.vrf, and 'vrf' is registered as an
editable text extension. The dedicated in-UI editor (and hiding it from the
file tree) follows in a separate change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/python-dependencies-design.md

@@ -7,7 +7,7 @@ beyond the curated base set.
 
 ## What ships in Phase 1
 
-- A project root `requirements.txt` is installed into a venv cached by its
+- A project root `requirements.vrf` is installed into a venv cached by its
   sha256, created with `python3 -m venv --system-site-packages`; `QuartoRunner`
   points Quarto at it via `QUARTO_PYTHON`. A per-hash `flock` serialises
   concurrent builds; pip output is merged into `output.log`; on failure the
@@ -21,7 +21,7 @@ beyond the curated base set.
 
 ### Known Phase-1 limitations
 
-- The first build of a heavy `requirements.txt` runs within the compile
+- The first build of a heavy `requirements.vrf` runs within the compile
   timeout; a very large install can be killed and retried next compile (the
   venv is only marked complete on success).
 - No egress restriction yet (Phase 2) — installs reach PyPI directly.
@@ -47,15 +47,15 @@ security decision, not just a convenience.
 
 ## Mechanism
 
-1. **Declaration.** A standard `requirements.txt` at the project root opts the
+1. **Declaration.** A standard `requirements.vrf` at the project root opts the
    project in (familiar, Quarto-agnostic, supports version pinning).
-2. **Keying.** CLSI hashes `sha256(requirements.txt + python version)`. The hash
+2. **Keying.** CLSI hashes `sha256(requirements.vrf + python version)`. The hash
    names a venv directory on a **persistent volume**, e.g.
    `…/data/python-venvs/<hash>/`. Identical dependency sets share one venv across
    projects and compiles.
 3. **Build-if-missing.** `python3 -m venv --system-site-packages <dir>` (so the
    bundled stack stays visible and only the *extra* deps are installed — smaller
-   and faster), then `<dir>/bin/pip install -r requirements.txt`. Guard with a
+   and faster), then `<dir>/bin/pip install -r requirements.vrf`. Guard with a
    per-hash `flock` so concurrent compiles don't build the same venv twice.
 4. **Point Quarto at it.** Set `QUARTO_PYTHON=<dir>/bin/python3` in the render
    environment (threaded web → CLSI exactly like `exportMode`). With
@@ -93,7 +93,7 @@ security decision, not just a convenience.
 
 ## Open decisions
 
-- `requirements.txt` vs a frontmatter field vs both?
+- `requirements.vrf` vs a frontmatter field vs both?
 - Shared global venv volume vs per-user namespacing (sharing is cheaper;
   per-user is stricter isolation)?
 - Allow native/compiled wheels (broader support) vs wheels-only/no-build