feat: Dockerfile und Compose -- geschrieben, aber nie gebaut

Auf dieser Maschine gibt es weder Docker noch WSL. Das Abbild ist also
ungebaut und der Container nie gelaufen; das gehoert auf eine Maschine
mit Docker, bevor jemand darauf baut.

Was trotzdem geprueft ist:

Node 22 ist festgenagelt, und das ist kein Zufall. better-sqlite3 11.10.0
liefert fertige Binaerdateien nur fuer ABI 108 (Node 20), 115, 127
(Node 22) und 131 -- Node 24 hat ABI 137 und fehlt. Der naheliegende
Griff zur neuesten Version faellt damit auf node-gyp zurueck und braucht
python3, make und g++ im Abbild. Aus den Veroeffentlichungen des Projekts
abgelesen, nicht aus dem Gedaechtnis.

node dist/index.js -- der Startbefehl des Abbilds -- laeuft und antwortet
auf /health. Bis hierher war der Dienst nur je ueber tsx gestartet
worden. Der Healthcheck gibt Exitcode 0 bei laufendem und 1 bei totem
Dienst.

Dazu eine Falle, die im Compose steht, weil sie teuer ist:
NODE_ENV=production setzt das Sitzungs-Cookie auf Secure. Wer den
Container ohne HTTPS aufruft, bekommt auf die Anmeldung 200 -- und ist
trotzdem nicht angemeldet, weil der Browser das Cookie still verwirft.
Die naechste Anfrage ist 401. Im Browser gegen eine LAN-Adresse
nachgemessen. Die naheliegende Gegenprobe ueber localhost fuehrt in die
Irre: das gilt Browsern als sicherer Kontext und funktioniert.

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

ROADMAP.md

@@ -178,10 +178,37 @@ es weiterhin keine API.
 
 ### ⬜ Als Nächstes
 
-**2 · Dockerfile und Compose.** Ein Abbild, das Server und gebaute Oberfläche
-ausliefert; ein Volume für `data/`; ein Port für NPM. In Portainer aus diesem
-Repo deploybar — **`Compose path` nimmt EINE Datei**, Ergänzungen werden
-stillschweigend ignoriert. Das hat uns bei Lite einen Nachmittag gekostet.
+**2 · Dockerfile und Compose — geschrieben, aber NIE GEBAUT.**
+`server/Dockerfile` und `docker-compose.media.yml` stehen. Auf der Maschine,
+auf der sie entstanden sind, gibt es weder Docker noch WSL — das Abbild ist
+also ungebaut und der Container nie gelaufen. Das ist der nächste Handgriff,
+und er gehört auf eine Maschine mit Docker.
+
+Was daran trotzdem geprüft ist:
+
+- **Node 22 ist festgenagelt, mit Grund.** `better-sqlite3` 11.10.0 liefert
+  fertige Binärdateien nur für ABI 108 (Node 20), 115, 127 (Node 22) und 131.
+  **Node 24 hat ABI 137 und fehlt** — der naheliegende Griff zur neuesten
+  Version fällt auf `node-gyp` zurück und braucht python3, make und g++ im
+  Abbild. Aus den Veröffentlichungen des Projekts abgelesen, nicht geraten.
+- **`node dist/index.js`** — der Startbefehl des Abbilds — läuft und antwortet
+  auf `/health`. Bis dahin war der Dienst nur je über `tsx` gestartet.
+- **Der Healthcheck** gibt Exitcode 0 bei laufendem und 1 bei totem Dienst.
+
+Ungeprüft bleibt alles, wofür es Docker braucht: ob `npm ci` im Abbild die
+Binärdatei zieht, ob das Volume greift, ob der Bau überhaupt durchläuft.
+
+> **Beim Ausprobieren:** `NODE_ENV=production` setzt das Sitzungs-Cookie auf
+> `Secure`. Wer den Container ohne HTTPS aufruft, bekommt auf die Anmeldung
+> **200 — und ist trotzdem nicht angemeldet**, weil der Browser das Cookie
+> still verwirft; die nächste Anfrage ist 401. Im Browser gegen eine
+> LAN-Adresse nachgemessen. Die naheliegende Gegenprobe über `localhost`
+> führt in die Irre: das gilt Browsern als sicherer Kontext und funktioniert.
+
+In Portainer aus diesem Repo deploybar — **`Compose path` nimmt EINE Datei**,
+Ergänzungen werden stillschweigend ignoriert. Das hat uns bei Lite einen
+Nachmittag gekostet. Host-Port ist 9102, solange der Lite-Stack 9100/9101
+belegt.
 
 **3 · `server/upload.lua` im Fotostudio.** `Upload.put(pfad, bytes) → url`.
 Token in `config.upload.lua`, server-only, gitignored, mit committetem