Vereinheitliche Stack-Steuerung auf scripts/lab.sh

Eine einzige Quelle der Wahrheit fuer alle Stack-Aktionen statt
doppelt gepflegter Verb-Tabellen in Makefile und PowerShell-Wrapper.

- scripts/lab.sh: zentraler Dispatcher (bootstrap/up/redeploy/
  proxy-reload/down/logs/reset/reset-hard/reset-origin)
- workshop.ps1: switch-Tabelle kollabiert zu Delegation an lab.sh
  (kein --remove-orphans-Drift mehr zwischen den Oberflaechen)
- Makefile entfernt: WSL/Ubuntu bringt make nicht standardmaessig
  mit, Doku-Verben (make X) passten nicht zur PowerShell-Mehrheit
- bootstrap.sh: Logik inline, redundante bootstrap-unix.sh und
  bootstrap-wsl.sh entfernt
- Doku/HTML: alle 32 "make X" -> "./scripts/lab.sh X", Prosa
  (macOS-make-Hinweis, PowerShell-Wrapper-Text) angepasst

Verifiziert: bootstrap -> proxy-reload -> redeploy -> reset laufen
end-to-end gegen den Stack, Basisrouten und Done-Checks gruen.

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

challenges/README.md

@@ -12,7 +12,7 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
 
 Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wichtig:
 
-- **Stack steuern** (`make ...` oder der PowerShell-Wrapper `scripts/workshop.ps1`): geht aus PowerShell **oder** aus dem WSL-Terminal.
+- **Stack steuern** (`./scripts/lab.sh ...` in WSL oder der PowerShell-Wrapper `scripts/workshop.ps1`): geht aus PowerShell **oder** aus dem WSL-Terminal.
 - **Alle Challenge-Kommandos** (`curl`, `openssl`, `grep`, `wget`, `for`-Schleifen, `./scripts/compose.sh ...`): laufen im **WSL-Terminal (bash)**, nicht in PowerShell.
 - **Warnung:** In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die hier genutzten Flags (`-I`, `-k`, `--cacert`) **nicht**. Immer im WSL-Terminal testen.
 - Das Repo liegt im WSL-Dateisystem oder unter `/mnt/c/...`; arbeite am besten aus dem WSL-Terminal im Projektordner.
@@ -20,7 +20,7 @@ Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wich
 ## Arbeitsmodus
 
 1. Dateien anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
-2. Deployen: nach reinen `nginx.conf`-Aenderungen reicht `make proxy-reload`; nach Aenderungen an `docker-compose.yml` (z. B. neue Ports oder Services) immer `make redeploy`, da der Container neu erstellt werden muss.
+2. Deployen: nach reinen `nginx.conf`-Aenderungen reicht `./scripts/lab.sh proxy-reload`; nach Aenderungen an `docker-compose.yml` (z. B. neue Ports oder Services) immer `./scripts/lab.sh redeploy`, da der Container neu erstellt werden muss.
 3. Testen mit `curl` / `openssl` / Wireshark.
 4. Bei Problemen: `./scripts/compose.sh logs reverse-proxy`.
 
@@ -29,7 +29,7 @@ Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wich
 - Es wird **additiv in einer einzigen `proxy/nginx.conf`** gearbeitet: jede Challenge erweitert den Stand der vorherigen. Loesungen nicht wieder loeschen - die TLS-Challenges (10-12) bauen direkt aufeinander auf.
 - **Ausnahme Challenge 9** (Debugging): Diese ueberschreibt die `nginx.conf` bewusst. Vorher sichern (`cp proxy/nginx.conf proxy/nginx.conf.bak`), danach wiederherstellen.
 - Jede Angabe nennt einen **Ausgangszustand** (worauf baue ich auf) und einen **Zielzustand / Akzeptanz** (woran erkenne ich "fertig"). Der Done-Check ist die pruefbare Form des Zielzustands.
-- Komplett zuruecksetzen geht jederzeit mit `make reset` (Container/Volumes) bzw. `make reset-hard` (zusaetzlich lokale Datei-Aenderungen verwerfen).
+- Komplett zuruecksetzen geht jederzeit mit `./scripts/lab.sh reset` (Container/Volumes) bzw. `./scripts/lab.sh reset-hard` (zusaetzlich lokale Datei-Aenderungen verwerfen).
 
 ---
 
@@ -77,7 +77,7 @@ curl http://localhost:8080/service/b   # -> "Reverse Proxy Target B"
 **Schritte (Muss)**
 - Service `backend-c` in Compose einbauen.
 - Upstream + Route `/service/c` in Nginx anlegen.
-- Deployen mit `make redeploy` (Compose-Aenderung -> Container-Neustart noetig).
+- Deployen mit `./scripts/lab.sh redeploy` (Compose-Aenderung -> Container-Neustart noetig).
 
 **Zielzustand / Akzeptanz**
 - `/service/c` liefert Backend C.
@@ -104,7 +104,7 @@ curl http://localhost:8080/service/b   # -> weiterhin "Reverse Proxy Target B"
 **Schritte (Muss)**
 - Route `/demo/a` anbieten, die auf Backend A fuehrt.
 - Entweder per rewrite oder per eigener proxy-Route loesen.
-- Deployen mit `make proxy-reload`.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Zielzustand / Akzeptanz**
 - `/demo/a` liefert dieselbe Antwort wie `/service/a` (Backend A), obwohl der externe Pfad ein anderer ist.
@@ -138,7 +138,7 @@ curl http://localhost:8080/demo/a   # -> "Reverse Proxy Target A"
   - `Cross-Origin-Opener-Policy: same-origin`
   - `Cross-Origin-Resource-Policy: same-origin`
 - Optional (Bonus): `Content-Security-Policy` fuer statische Seiten (mit Inline-Styles bewusst beruecksichtigen)
-- Deployen mit `make proxy-reload`.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Fallstrick (`add_header`-Vererbung)**
 - Header am besten **einmal im `server {}`-Block** setzen, dann gelten sie fuer alle Locations.
@@ -167,7 +167,7 @@ curl -I http://localhost:8080/
 **Schritte (Muss)**
 - Route `/internal/status` bauen.
 - Nur `127.0.0.1` erlauben, alle anderen verbieten.
-- Deployen mit `make proxy-reload`.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Wichtiger Hinweis**
 - Host-Request ueber `localhost:8080` kommt aus Docker-Sicht oft **nicht** von `127.0.0.1`.
@@ -198,7 +198,7 @@ curl -i http://localhost:8080/internal/status
 **Schritte (Muss)**
 - Eigenes `log_format` mit Upstream-Infos anlegen.
 - Access-Log auf das neue Format umstellen.
-- Deployen mit `make proxy-reload`.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Hinweis**
 - `log_format` gehoert in den `http {}`-Block (nicht in `server {}` oder `location {}`), sonst startet Nginx mit `"log_format" directive is not allowed here` nicht. `access_log` darf in `http`, `server` oder `location` stehen.
@@ -232,7 +232,7 @@ curl http://localhost:8080/service/a
 - Zweite Instanz von Backend A (`backend-a2`) anlegen.
 - `upstream backend_a` auf beide Instanzen erweitern.
 - Mehrfach-Requests zeigen, dass beide Instanzen antworten.
-- Deployen mit `make redeploy` (Compose-Aenderung).
+- Deployen mit `./scripts/lab.sh redeploy` (Compose-Aenderung).
 
 **Zielzustand / Akzeptanz**
 - Bei mehreren Aufrufen von `/service/a` antworten **beide** Instanzen (Round-Robin), also sowohl `Target A` als auch `Target A2`.
@@ -261,7 +261,7 @@ done
 - Mit `proxy_hide_header` mindestens einen durchgereichten Backend-Header ausblenden
   (z. B. `ETag`, `Last-Modified`).
 - Kurz erklaeren, warum weniger Fingerprinting-Infos hilfreich sind.
-- Deployen mit `make proxy-reload`.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Abgrenzung zu Challenge 4**
 - Challenge 4 setzt aktive Schutz-Header.
@@ -337,7 +337,7 @@ curl http://localhost:8080/service/b   # -> "Reverse Proxy Target B"
 - CA + Server-Zertifikat fuer `localhost` mit SAN erstellen (`--subject-alt-name="DNS:localhost,IP:127.0.0.1"`).
 - Nur Runtime-Cert + Key bereitstellen (nicht die ganze PKI mounten).
 - Proxy auf `443` erweitern (Mapping `8443:443`) und TLS in Nginx aktivieren.
-- Mit `make redeploy` deployen (Compose-Aenderung -> Container-Neustart noetig).
+- Mit `./scripts/lab.sh redeploy` deployen (Compose-Aenderung -> Container-Neustart noetig).
 - Root-CA in den System-Trust-Store importieren.
 
 **Zielzustand / Akzeptanz**
@@ -376,7 +376,7 @@ curl --cacert certs/easyrsa/pki/ca.crt https://localhost:8443/service/a
 **Schritte (Muss)**
 - HTTP Requests auf HTTPS redirecten (`return 301 https://$host:8443$request_uri;`).
 - `/healthz` darf optional auf HTTP bleiben.
-- Deployen mit `make proxy-reload` (reine `nginx.conf`-Aenderung).
+- Deployen mit `./scripts/lab.sh proxy-reload` (reine `nginx.conf`-Aenderung).
 
 **Zielzustand / Akzeptanz**
 - HTTP-Aufrufe auf `8080` antworten mit `301` und `Location: https://localhost:8443/...`.
@@ -409,7 +409,7 @@ curl -I http://localhost:8080/service/a
 - TLS auf 1.2/1.3 beschraenken (`ssl_protocols TLSv1.2 TLSv1.3;`).
 - HSTS setzen (`Strict-Transport-Security`).
 - Zertifikatskette pruefen und kurz erklaeren.
-- Deployen mit `make proxy-reload`.
+- Deployen mit `./scripts/lab.sh proxy-reload`.
 
 **Hinweis**
 - Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.