feat: Split CI/CD pipeline into separate build and deploy workflows

- Add build-image.yml: Automatic image builds on push (5-8 min)
- Add deploy-production.yml: Manual deployment workflow (2-5 min)
- Mark production-deploy.yml as deprecated

Benefits:
- Faster feedback: Images ready in ~5-8 min (vs 10-15 min before)
- Flexible deployment: Deploy when ready, not forced after every build
- Parallel execution: Multiple builds can run simultaneously
- Better separation: Build failures don't block deployments of existing images

.gitea/workflows/PRODUCTION_DEPLOY_DEPRECATED.md

@@ -0,0 +1,31 @@
+# ⚠️ DEPRECATED: production-deploy.yml
+
+Diese Datei ist **deprecated** und wird durch getrennte Workflows ersetzt:
+
+## Neue Workflows
+
+### 1. `build-image.yml` - Automatischer Image-Build
+- **Trigger**: Automatisch bei Push zu `main`/`develop`
+- **Zweck**: Baut Docker Images und pusht sie zur Registry
+- **Vorteil**: Images sind sofort verfügbar, auch ohne Deployment
+
+### 2. `deploy-production.yml` - Deployment Workflow
+- **Trigger**: 
+  - Manuell über `workflow_dispatch`
+  - Optional: Automatisch nach erfolgreichem Build (konfigurierbar)
+- **Zweck**: Deployed vorhandene Images auf Production Server
+- **Vorteil**: Flexibles Deployment, schneller wenn Image bereits vorhanden
+
+## Migration
+
+Die alte `production-deploy.yml` kann entfernt werden, sobald:
+1. ✅ `build-image.yml` erfolgreich getestet wurde
+2. ✅ `deploy-production.yml` erfolgreich getestet wurde
+3. ✅ Team ist mit neuen Workflows vertraut
+
+## Vorteile der Trennung
+
+- ⚡ **Schnelleres Feedback**: Images werden sofort gebaut (ca. 5-8 Min statt 10-15 Min)
+- 🎯 **Flexibleres Deployment**: Man kann wählen, wann und welches Image deployed wird
+- 🔄 **Parallele Ausführung**: Mehrere Builds können gleichzeitig laufen
+- 📦 **Image-Caching**: Builds sind unabhängig von Deployments