feat(k8s): Sicherung und Hintergrund-Jobs lauffaehig machen

- Werkzeug-Image wabenhain-tools (Dockerfile "AS tools", Muster wie
  artista-modelcamp-tools): Im App-Image fehlten tsconfig.json und Pakete
  wie stripe, Bestandsabgleich und Bestellfreigabe brachen mit
  "Cannot find module" ab. Die CI baut es neben dem App-Image.
- Datenbank-Sicherung: PV auf der Storage Box (Customer/Wabenhain), der
  Unterordner db-backup entsteht per subPath. Vorher blieb der PVC ohne
  StorageClass haengen.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

k8s/07-backup-cronjob.yaml

@@ -8,9 +8,9 @@
 # ausserdem einer zehnjaehrigen Aufbewahrungspflicht (§ 147 AO) — ein
 # Datenverlust ist hier nicht nur aergerlich, sondern ein Rechtsproblem.
 #
-# Diese Sicherung liegt bewusst NUR im Cluster. Sie schuetzt gegen
-# Volume-Verlust und Bedienfehler, nicht gegen den Ausfall des gesamten
-# Clusters oder Standorts. Fuer eine vollstaendige Absicherung die
+# Diese Sicherung liegt auf derselben Storage Box wie die Datenbank. Sie
+# schuetzt gegen Volume-Verlust und Bedienfehler, nicht gegen den Ausfall
+# der Storage Box oder des Standorts. Fuer eine vollstaendige Absicherung die
 # erzeugten .sql.gz-Dateien zusaetzlich regelmaessig aus dem Cluster
 # herausziehen (Beispielbefehl siehe k8s/README.md, Abschnitt "Sicherung
 # und Wiederherstellung").
@@ -20,6 +20,33 @@
 # pg_dump-Aufruf unten ersetzen durch:
 #   mysqldump -h wabenhain-mysql -u wabenhain -p"$PGPASSWORD" \
 #     --single-transaction --routines wabenhain | gzip -9 > "$file.partial"
+# Ziel ist die Storage Box wie bei den uebrigen Wabenhain-Volumes. Das PV
+# zeigt auf den vorhandenen Ordner Customer/Wabenhain; der Unterordner
+# db-backup entsteht ueber subPath beim ersten Lauf.
+apiVersion: v1
+kind: PersistentVolume
+metadata:
+  name: wabenhain-db-backup
+spec:
+  capacity:
+    storage: 10Gi
+  accessModes:
+    - ReadWriteOnce
+  persistentVolumeReclaimPolicy: Retain
+  storageClassName: ""
+  mountOptions: ["vers=3.0", "uid=70", "gid=70", "dir_mode=0700", "file_mode=0600", "noperm"]
+  csi:
+    driver: smb.csi.k8s.io
+    volumeHandle: wabenhain-db-backup
+    volumeAttributes:
+      source: //u652065.your-storagebox.de/backup/Server/Disks/Customer/Wabenhain
+    nodeStageSecretRef:
+      name: smb-credentials
+      namespace: wabenhain
+  claimRef:
+    namespace: wabenhain
+    name: wabenhain-db-backup
+---
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
@@ -28,7 +55,8 @@ metadata:
 spec:
   accessModes:
     - ReadWriteOnce
-  # storageClassName: "dein-storage-class"
+  storageClassName: ""
+  volumeName: wabenhain-db-backup
   resources:
     requests:
       # Eine gzip-komprimierte Sicherung dieses Datenbestandes liegt im
@@ -136,6 +164,7 @@ spec:
               volumeMounts:
                 - name: backup
                   mountPath: /backup
+                  subPath: db-backup
                 # Nur lesend: dieser Job darf Belege sichern, niemals aendern.
                 - name: invoices
                   mountPath: /invoices
@@ -209,17 +238,17 @@ spec:
         spec:
           restartPolicy: OnFailure
           # Gleiche Kennung wie der App-Container (Dockerfile: adduser --uid
-          # 1001 nextjs) — dasselbe Image, derselbe Nutzer.
+          # 1001 nextjs) — beide Images legen denselben Nutzer an.
           securityContext:
             runAsUser: 1001
             runAsGroup: 1001
           containers:
             - name: release-stale-orders
-              # DASSELBE Image und derselbe Tag wie in 05-app-deployment.yaml.
-              # Beide zusammen aktualisieren: der Lauf nutzt denselben
-              # Prisma-Client wie die App und muss deshalb zum selben
-              # Datenbankschema passen.
-              image: git.encry.de/nick.rosenloecher/wabenhain:latest
+              # Werkzeug-Image (Dockerfile "AS tools") mit DEMSELBEN Tag wie
+              # das App-Image in 05-app-deployment.yaml. Beide zusammen
+              # aktualisieren: der Lauf nutzt denselben Prisma-Client wie die
+              # App und muss deshalb zum selben Datenbankschema passen.
+              image: git.encry.de/nick.rosenloecher/wabenhain-tools:latest
               imagePullPolicy: IfNotPresent
               # Braucht DATABASE_URL, DATABASE_PROVIDER und STRIPE_SECRET_KEY
               # — die stehen bereits in denselben beiden Quellen wie fuer die
@@ -278,8 +307,8 @@ spec:
             runAsGroup: 1001
           containers:
             - name: apicore-stock
-              # DASSELBE Image und derselbe Tag wie in 05-app-deployment.yaml.
-              image: git.encry.de/nick.rosenloecher/wabenhain:latest
+              # Werkzeug-Image mit demselben Tag wie in 05-app-deployment.yaml.
+              image: git.encry.de/nick.rosenloecher/wabenhain-tools:latest
               imagePullPolicy: IfNotPresent
               # Braucht DATABASE_URL, DATABASE_PROVIDER, APICORE_API_URL und
               # APICORE_API_KEY — dieselben Quellen wie die App.