fix(deploy): leere Argumente und eine fehlende .env brachen das Deploy - still

Zwei Funde beim Deployen, beide fuer die Weitergabe relevant:

1. `./deploy.sh` ohne Argumente - der dokumentierte Normalfall - endete mit
   "line 5: $4: unbound variable". Leere Argumente ueberleben den Weg durch ssh
   nicht: Die Gegenseite bekommt die Befehlszeile als EINEN String und parst sie
   neu, wobei "" ersatzlos verschwindet. ${4:-} statt "$4".

2. Fehlte die .env-Quelle, war das eine geschluckte Warnung. Auf der Ziel-VM lag
   die echte .env unter ~/projects/rippy/.env, der Default zeigte auf
   ~/rippy/.env. Das `cp` schlug also jedes Mal fehl, die Warnung scrollte im
   Build-Rauschen vorbei, und gebaut wurde mit der Kopie im Klon: zwei Tage alt,
   darin ein MAKEMKV_URL_BASE-Notbehelf auf einen web.archive.org-Schnappschuss
   (liefert inzwischen 525, waehrend makemkv.com wieder 200 gibt) und ein
   JWT_SECRET_KEY aus der Zeit vor dem Auth-Rueckbau. Jeder worker-Build brach
   daran ab, und die Ursache stand nirgends.

Jetzt: .env uebernommen -> es steht da. Quelle fehlt, Klon hat eine -> laute
Warnung samt Dateidatum und Kandidatenliste. Keine von beiden -> Abbruch, statt
mit leerem DB-Passwort zu bauen.

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

deploy.sh

@@ -34,7 +34,12 @@ set -euo pipefail
 REPO_URL="$1"
 ENV_SRC="${2:-$HOME/rippy/.env}"
 CLONE="${3:-$HOME/notfall-rippy}"
-DIENST="$4"
+# ⚠️ ${4:-}, nicht "$4" (Befund 26.07.2026): Leere Argumente ueberleben den Weg
+# durch ssh nicht — die Gegenseite bekommt die Befehlszeile als EINEN String und
+# parst sie neu, wobei "" ersatzlos verschwindet. Wer also ohne RIPPY_ENV_SRC,
+# RIPPY_CLONE und ohne Dienst-Argument deployte (der dokumentierte Normalfall!),
+# bekam von 'set -u' nur ein "line 5: $4: unbound variable" und kein Deploy.
+DIENST="${4:-}"
 
 # ⚠️ NICHT DEPLOYEN, WÄHREND EIN JOB LÄUFT (Vorfall 26.07.2026, selbst verursacht)
 #
@@ -64,7 +69,28 @@ fi
 cd "$CLONE"
 git fetch origin main
 git reset --hard origin/main
-cp "$ENV_SRC" .env 2>/dev/null || echo "WARNUNG: keine .env unter $ENV_SRC gefunden"
+# ⚠️ Eine fehlende .env-Quelle war bisher eine geschluckte Warnung — und damit
+# eine Falle (Befund 26.07.2026). Auf der Ziel-VM lag die echte .env unter
+# ~/projects/rippy/.env, der Default zeigte auf ~/rippy/.env. Das `cp` schlug
+# also jedes Mal fehl, die Zeile scrollte im Build-Ausgabe-Rauschen vorbei, und
+# gebaut wurde mit der Kopie im Klon: zwei Tage alt, mit einem inzwischen toten
+# MAKEMKV_URL_BASE-Notbehelf und einem JWT_SECRET_KEY aus der Zeit vor dem
+# Auth-Rueckbau. Ergebnis: jeder worker-Build brach ab, und die Ursache stand
+# nirgends.
+if [ -f "$ENV_SRC" ]; then
+  cp "$ENV_SRC" .env
+  echo "OK: .env aus $ENV_SRC uebernommen."
+elif [ -f .env ]; then
+  echo "WARNUNG: $ENV_SRC gibt es nicht — es gilt die .env IM KLON ($CLONE/.env)." >&2
+  echo "         Stand dieser Datei: $(date -r .env '+%d.%m.%Y %H:%M')" >&2
+  echo "         Ist das nicht gewollt: RIPPY_ENV_SRC=<pfad> setzen." >&2
+  ls -1 "$HOME"/*/.env "$HOME"/*/*/.env 2>/dev/null | head -5 | sed 's/^/         Kandidat: /' >&2 || true
+else
+  echo "ABBRUCH: Keine .env — weder unter $ENV_SRC noch im Klon." >&2
+  echo "         Ohne sie baut compose mit leeren Werten (kein DB-Passwort," >&2
+  echo "         keine API-Schluessel). RIPPY_ENV_SRC=<pfad> setzen." >&2
+  exit 1
+fi
 docker compose -p rippy up -d --build $DIENST
 docker compose -p rippy ps --format 'table {{.Name}}\t{{.Status}}'
 REMOTE