Produktiver WSGI-Server (Gunicorn) statt Flasks Entwicklungsserver

tesm.service startete die App bisher direkt per 'python3 app.py', was
Flasks eingebauten Werkzeug-Entwicklungsserver nutzt -- der meldet bei
jedem Start 'WARNING: This is a development server. Do not use it in a
production deployment.' und ist bewusst nicht für Dauerbetrieb gebaut.

Umgestellt auf Gunicorn, mit zwei bewusst gesetzten Einschraenkungen:
- '--workers 1': die App haelt laufende Wartungs-Jobs/Import-Vorschauen
  nur im Arbeitsspeicher DES EINEN Prozesses (_maintenance_jobs,
  _pending_imports, ...) -- mehrere Worker-Prozesse wuerden diesen
  Zustand auf mehrere, sich nicht kennende Prozesse verteilen.
- '--worker-class gthread --threads 16' statt eines async-Workers: das
  Browser-SSH-Terminal (flask-sock) belegt pro offener WebSocket-
  Verbindung einen blockierenden Thread.
- '--timeout 0': deaktiviert Gunicorns eigenen 30s-Worker-Timeout, der
  sonst auch eine offene, aber gerade inaktive SSH-Terminal-Verbindung
  killen wuerde.

Live auf POETEST verifiziert: keine WARNING-Zeile mehr, genau 1 Master-
+ 1 Worker-Prozess, alle Kernseiten weiterhin 200, und als kritischer
Regressionstest das WebSocket-SSH-Terminal Ende-zu-Ende gegen einen
echten Host erfolgreich getestet (Host-Key/Passwort-Prompt/Login/Shell).

Dabei einen unabhaengigen Altlast-Fehler in POETESTs venv gefunden und
allgemein in install.sh gefixt: './venv/bin/pip' hat eine zur
Venv-Erstellung fest einprogrammierte Shebang-Zeile -- nach der
historischen Umbenennung 'poe_manager' -> 'tesm' zeigte sie auf einen
nicht mehr existierenden Pfad und schlug mit 'cannot execute: required
file not found' fehl. 'python3 -m pip' umgeht das, da nur der (korrekt
referenzierte) venv-Python-Interpreter selbst gebraucht wird -- betrifft
sonst auch jedes kuenftige In-Place-Update auf einem aehnlich
gewachsenen Host.

install.sh

@@ -45,11 +45,20 @@ sudo rsync -a --delete --exclude 'venv' --exclude 'sqlite.db' --exclude 'fernet.
 print_status "Application files copied"
 
 # ---- Python venv ----
+# "python3 -m pip" statt des "pip"-Skripts im venv selbst: dessen Shebang
+# enthält einen zur Erstellungszeit FEST einprogrammierten, absoluten Pfad
+# zum venv-Python. Wird das venv-Verzeichnis später umbenannt/verschoben
+# (wie hier historisch bei der Umbenennung "poe_manager" -> "tesm"
+# passiert), bleibt die alte, nicht mehr existierende Pfadangabe stehen --
+# "./venv/bin/pip install ..." schlägt dann mit "cannot execute: required
+# file not found" fehl (live auf POETEST reproduziert), obwohl das venv
+# selbst voll funktionsfähig ist. "python3 -m pip" braucht dagegen nur den
+# (korrekt referenzierten) venv-Python-Interpreter selbst.
 step "Setting up Python virtual environment"
 cd /srv/tesm
 sudo python3 -m venv venv
-sudo ./venv/bin/pip install --upgrade pip >>/var/log/tesm-install.log 2>&1
-sudo ./venv/bin/pip install -r requirements.txt >>/var/log/tesm-install.log 2>&1
+sudo ./venv/bin/python3 -m pip install --upgrade pip >>/var/log/tesm-install.log 2>&1
+sudo ./venv/bin/python3 -m pip install -r requirements.txt >>/var/log/tesm-install.log 2>&1
 print_status "Virtual environment ready"
 
 # ---- Datenbank ----