feat: Sicherung, Anmeldebremse, Vorschaubilder -- und Schritt 5

SICHERUNG (tools/sichern.ps1, taeglich 04:30 als geplante Aufgabe).
Die Datenbank wird nicht kopiert, sondern ueber SQLites eigene
Sicherungsschnittstelle herausgeholt (server/src/backup.ts): im WAL-Modus
liegt das Zuletzte noch nicht in media.db, und selbst alle drei Dateien zu
kopieren ist nicht sicher, wenn waehrenddessen geschrieben wird. Die Bilder
kommen aus einem NUR LESEND eingehaengten Volume dazu.

Und sie prueft sich selbst: auspacken, Datenbank oeffnen, Medien/Token/
Benutzer zaehlen, mit dem laufenden Dienst vergleichen, sonst Fehler. Einmal
wirklich zurueckgespielt -- leeres Volume, zweiter Dienst, Anmeldung mit dem
echten Passwort, Bild abgerufen, Byte fuer Byte identisch. Eine Sicherung, die
nie zurueckgespielt wurde, ist eine Hoffnung.

ANMELDEBREMSE. Das Formular steht oeffentlich, und scrypt macht einen Versuch
teuer -- aber teuer ist nicht selten. Fuenf freie Versuche je Adresse, dann
Sperre ab 30 s mit Verdopplung bis 15 min, 429 samt Retry-After und einem Text,
der sagt wie lange. Erfolg setzt zurueck. Nur im Speicher: wer sich aussperrt,
startet den Container neu. Durchgemessen bis zur Erholung.

VORSCHAUBILDER. sharp erzeugt beim Upload eine 320er WebP-Fassung unter
/data/thumbs, ausgeliefert unter /t/<pfad>. Gemessen: 131502 -> 13078 Bytes,
Faktor 10; eine Galerieseite faellt von 7,5 MB auf 766 KB. KEINE Spalte in der
Datenbank -- ob es eine Vorschau gibt, sagt das Dateisystem, und die Galerie
faellt bei 404 aufs Vollbild zurueck. Eine zweite Wahrheit, die auseinander-
laufen kann, gibt es damit gar nicht erst. Ein Knopf zieht Fehlendes nach und
nennt Zahlen statt "fertig".

SCHRITT 5. Die Fivemanage-Dateien liegen in legacy/ mit Erklaerung; unsere
docker-compose.media.yml heisst jetzt docker-compose.yml. Drei Volumes und drei
Abbilder geloescht, rund 670 MB -- nachgezaehlt war vorher, dass kein Bild
darin lag.

Nebenbefund: `npm i sharp` scheitert auf diesem Rechner nicht an sharp, sondern
an better-sqlite3 -- der Host laeuft auf Node 24 (ABI 137), node-gyp uebernimmt
und findet keine Bauwerkzeuge. Genau die Falle aus dem Dockerfile. Eingetragen
wurde mit --package-lock-only, gebaut wird im Abbild auf Node 22.

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

legacy/docker-compose.proxynet.yml

@@ -0,0 +1,37 @@
+# Ergaenzung fuer einen Reverse Proxy, der IM SELBEN Docker-Netz haengt.
+#
+# Der sauberere der beiden Wege: kein Port muss auf dem Host offen sein, der
+# Proxy spricht die Container direkt an.
+#
+#   docker compose -f docker-compose.yml -f docker-compose.proxynet.yml up -d
+#
+# NICHT ueber Portainer aus dem Repo: dort nimmt "Compose path" nur EINE
+# Datei, und eine Ergaenzung wird stillschweigend ignoriert. Wer diesen Weg
+# will, fuehrt die beiden Dateien zusammen oder startet von Hand.
+#
+# VORAUSSETZUNG: das Netz muss es schon geben, und der Proxy muss darin
+# haengen. Nachsehen:
+#
+#   docker network ls
+#   docker network inspect <name>       zeigt die Mitglieder
+#
+# Haengt der Proxy nirgends mit drin, ist das hier der falsche Weg — dann
+# bleibt es bei den Host-Ports aus docker-compose.yml, die dann auch offen
+# bleiben duerfen. Ein Netz anzulegen, in dem nur diese Container sitzen,
+# bringt nichts: der Proxy muesste mit hinein.
+#
+# Danach in NPM:
+#   fivecdn.d4rkst3r.de  ->  http://minio:9000
+#   <oberflaeche>        ->  http://lite:8080
+
+services:
+  minio:
+    networks: [internal, proxy]
+
+  lite:
+    networks: [internal, proxy]
+
+networks:
+  proxy:
+    name: ${PROXY_NETWORK:-proxy}
+    external: true