Notebook-Tests: nbmake + Subprocess-Zellen + inkrementeller Test

Alle 25 Notebooks sind nun fehlerfrei testbar (25 passed). Dafür drei
Änderungen im Build und eine neue Test-Infrastruktur:

1. pyproject.toml: nbmake>=1.5 in der dev-Gruppe.

2. build_version_04.py: Notebooks bekommen zwei Setup-Zellen und
   Subprocess-Zellen für Programme, die nicht direkt im Kernel laufen:
   - NOTEBOOK_SETUP_2: __file__ definieren, sys.path für or_kern,
     multiprocessing auf fork (Spawn findet Kernel-Funktionen nicht).
   - _braucht_subprocess: erkennt highspy (Solver-Konflikt), pytest
     (SystemExit), get_context('spawn'), subprocess+__file__ (sucht
     .py-Dateien), sys.exit (SystemExit). Diese Programme erscheinen
     als Markdown-Codeblock (sichtbar, nicht ausführbar) plus einer
     Subprocess-Zelle mit NO_COLOR=1 (verhindert ANSI-Codes, die der
     Parser von Mutationstest.py nicht verarbeitet).
   - Solver-Konflikt-Erkennung: wenn ein Kapitel sowohl ortools als
     auch highspy importiert, laufen auch reine ortools-Programme als
     Subprocess (highspy schon im Kernel).

3. teste_code_04.py: inkrementeller Test — nur geänderte/neue Programme
   und Notebooks (via git status). Netzabhängige Dateien (yfinance)
   werden automatisch erkannt und nur getestet, wenn Internet verfügbar.

4. PLAN.md Abschnitt 10: neuer Verifikationsschritt 4 (pytest --nbmake).
   PROGRESS.md und CLAUDE.md aktualisiert.

Gefundene und behobene Probleme:
- or_kern-Import: sys.path im Notebook erweitert.
- __file__ nicht definiert: zweite Setup-Zelle setzt es.
- multiprocessing spawn: fork erzwungen (Ein_System_Vier_Ansaetze.py).
- ortools/highspy-Konflikt: Subprocess für beide Solver.
- pytest SystemExit: Subprocess für test_or_kern.py und Mutationstest.py.
- sys.exit(0): Subprocess für Installationstest.py.
- ANSI-Codes in pytest-Ausgabe: NO_COLOR=1 in Subprocess-Zelle.

CLAUDE.md

@@ -174,6 +174,31 @@ Auch das `README.md` im Programme-Verzeichnis wird erzeugt — aus der Vorlage
 **`or_kern.py` ist der gemeinsame Unterbau** aller Programme (Domänenmodell, `SolverStatus`,
 `Loesung`-DTO, Abnahmeprüfung). Abgedruckt im Kapitel Praxisfallen.
 
+**Notebook-Tests (`nbmake`).** Seit September 2026 sind die 25 Notebooks ebenso
+getestet wie die Programme. `pyproject.toml` hat `nbmake>=1.5` in der `dev`-Gruppe;
+`PLAN.md` Abschnitt 10 enthält den zusätzlichen Verifikationsschritt
+`pytest --nbmake --nbmake-timeout=900 Notebooks_04/ -q`. Dafür müssen die Notebooks im
+Build drei Dinge mitbringen, die ein Programmskript nicht braucht:
+* **Zweite Setup-Zelle** (`NOTEBOOK_SETUP_2` in `build_version_04.py`): definiert
+  `__file__` (Programme nutzen es für `OUTPUT_DIR`), erweitert `sys.path` um das
+  Programmverzeichnis (`from or_kern import …`) und stellt multiprocessing auf `fork`
+  (der Spawn-Modus findet Kernel-Funktionen nicht).
+* **Subprocess-Zellen** für Programme, die nicht direkt im Kernel laufen:
+  `import highspy` (Solver-Konflikt mit ortools), `import pytest` (`SystemExit`),
+  `get_context("spawn")` (multiprocessing), `import subprocess` + `__file__` (sucht
+  andere .py-Dateien), `sys.exit(` (`SystemExit` im Kernel). Diese Programme erscheinen
+  als Markdown-Codeblock (sichtbar, nicht ausführbar) plus einer Subprocess-Zelle, die
+  das Programm mit `NO_COLOR=1` aufruft (sonst gibt pytest ANSI-Codes aus, die der
+  Ausgabe-Parser von `Mutationstest.py` nicht verarbeitet).
+* **`%pip`-Setup-Zelle** trägt das Tag `nbmake-skip` (wird von nbmake aktuell noch
+  ignoriert, aber als Dokumentation gedacht — die Zelle ist schnell, wenn Pakete schon
+  installiert sind).
+* **Inkrementeller Test** (`teste_code_04.py`): testet nur Programme und Notebooks,
+  die sich seit dem letzten Commit geändert haben (via `git status`). Netzabhängige
+  Dateien (yfinance) werden automatisch erkannt und nur getestet, wenn Internet
+  verfügbar ist. Aufruf: `python3 …/teste_code_04.py` (geänderte), `--alles`
+  (alle), `--check` (nur anzeigen).
+
 **`ortools` und `highspy` lassen sich nicht im selben Prozess importieren** (beide bringen
 eine eigene HiGHS-Kopie mit). Deshalb lädt `or_kern.py` Solverbibliotheken erst in der
 aufrufenden Funktion, und Programme, die beide brauchen, starten getrennte Prozesse (Muster: