feat: Admin-Seed automatisch beim Deploy ausfuehren

Bisher wurde nirgends automatisch ein erster Admin-User angelegt -
prisma/seed.ts existierte, war aber weder im Dockerfile-CMD noch sonst
irgendwo verdrahtet. Auf einer frischen Datenbank haette also niemand
sich einloggen koennen.

- Dockerfile-CMD: migrate:deploy && seed && node dist/main.js
- ts-node/typescript von devDependencies zu dependencies verschoben
  (seed.ts laeuft als rohes TypeScript zur Laufzeit, kein
  Kompilierschritt), tsconfig.json zusaetzlich ins Runtime-Image kopiert
- seed.ts gegen Unique-Constraint-Race bei mehreren gleichzeitig
  startenden Pod-Replicas gehaertet (P2002 abgefangen statt Absturz)
- Login-Banner im Log nur beim tatsaechlichen Erst-Anlegen (URL aus
  FRONTEND_ORIGIN, Benutzername, Passwort) - bewusst nicht bei jedem
  Neustart, sonst wuerden veraltete/geaenderte Zugangsdaten weiter
  geloggt und Credentials landen unnoetig dauerhaft in den Logs

Seed ist bereits idempotent per E-Mail-Check (auch bei deaktivierten
Usern), UsersService.assertNotLastSystemRoleUser verhindert ohnehin
das Deaktivieren des letzten aktiven Admins - kein Aenderungsbedarf
dort, siehe Konversation.

Verifiziert: tsc/eslint clean, 297/297 Tests, Build clean. Migration
und Schema live gegen die lokale DB bestaetigt (ueber WSL direkt, da
Windows->WSL-Portweiterleitung weiterhin kaputt ist); der eigentliche
Seed-Lauf selbst konnte nicht End-to-End gegen die DB verifiziert
werden (gleiches Verbindungsproblem), Banner-Ausgabe isoliert
smoke-getestet.

ApiCore-Backend/Dockerfile

@@ -15,15 +15,17 @@ COPY package.json package-lock.json ./
 RUN npm ci --omit=dev
 COPY --from=builder /app/dist ./dist
 COPY --from=builder /app/generated ./generated
-# schema.prisma, migrations/ und prisma.config.ts: noetig fuer
-# `npm run migrate:deploy`, das der Container beim Start selbst ausfuehrt
-# (siehe CMD unten), bevor der Server Verbindungen annimmt.
+# schema.prisma, migrations/, seed.ts und prisma.config.ts: noetig fuer
+# `npm run migrate:deploy` und `npm run seed`, die der Container beim Start
+# selbst ausfuehrt (siehe CMD unten), bevor der Server Verbindungen annimmt.
+# tsconfig.json: ts-node (Laufzeit-Dependency, siehe package.json) braucht es,
+# um seed.ts direkt auszufuehren, ohne separaten Kompilierschritt.
 COPY --from=builder /app/prisma ./prisma
 COPY --from=builder /app/prisma.config.ts ./prisma.config.ts
+COPY --from=builder /app/tsconfig.json ./tsconfig.json
 EXPOSE 3001
 USER node
 # migrate deploy ist idempotent und nutzt einen DB-seitigen Advisory-Lock,
-# daher unproblematisch bei mehreren gleichzeitig startenden Pod-Replicas:
-# eine Instanz wendet die Migrationen an, die anderen warten kurz und finden
-# danach nichts mehr zu tun.
-CMD ["sh", "-c", "npm run migrate:deploy && node dist/main.js"]
+# seed ist idempotent per Unique-Constraint auf User.email (siehe seed.ts) -
+# beides unproblematisch bei mehreren gleichzeitig startenden Pod-Replicas.
+CMD ["sh", "-c", "npm run migrate:deploy && npm run seed && node dist/main.js"]