Scan-Pfad entschlacken, Container-Limits setzen

Drei Änderungen, die den Spitzenverbrauch eines Stapelscans senken:

- Zuschnitte werden nicht mehr auf 1400 px hochgerechnet. Auf einem
  Stapelfoto ist eine Karte nur ein paar hundert Pixel breit; sie
  aufzublasen erzeugt vier Mal so viele Pixel ohne mehr Information und
  kostet zusätzlich Bildtokens beim Modellaufruf. OUT_WIDTH ist jetzt
  eine Obergrenze.
- Die um 180 Grad gedrehte Fassung entsteht erst, wenn ein Ergebnis leer
  bleibt, statt für jede Karte auf Vorrat. Das halbiert die
  JPEG-Kodierungen im Normalfall.
- Zuschnitte werden einzeln kodiert und sofort freigegeben, statt
  gesammelt im Speicher zu liegen.

Dazu mem_limit und cpus für den App-Container: ein Ausreißer soll den
Container treffen, nicht den Host, auf dem auch Jitsi und MySQL laufen.

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

docker-compose.yml

@@ -12,6 +12,11 @@ services:
     restart: unless-stopped
     # Wird im Workflow aus dem Secret DOTENV erzeugt.
     env_file: .env
+    # Deckel gegen Ausreisser: ein Stapelscan braucht im Normalfall deutlich
+    # unter 500 MB. Laeuft er aus dem Ruder, stirbt der Container - nicht der
+    # Host, auf dem auch Jitsi und die Datenbank liegen.
+    mem_limit: 1g
+    cpus: 1.5
     volumes:
       - business-card-scanner-data:/data
     networks: