docs: document pipeline fix v6 using direct config.json and sequential builds

Added a session log detailing the resolution of RAM-OOM issues and daemon interaction complexities by writing credentials directly to `config.json` and limiting jobs to sequential execution. Updated `.gitea/workflows/docker-publish.yaml` to reflect the simplified and rootless BuildKit configuration for internal HTTP registry access.

docs/99_Journal/2026-03-06_Session_Log_Pipeline_Fix_v3.md

@@ -77,7 +77,8 @@ BuildKit → http://git.mo-code.at:80
 | v2      | connection refused Port 443        | socat :80 → :3000                | socat nicht da       |
 | v3      | socat nicht verfügbar              | iptables DNAT                    | Permission denied    |
 | v4      | iptables — kein sudo-Recht         | buildkitd Mirror (kein Root)     | HTTP→HTTPS Fehler    |
-| **v5**  | login-action: HTTP→HTTPS-Konflikt  | **daemon.json + systemctl restart** | ✅ erwartet grün  |
+| v5      | login-action: HTTP→HTTPS-Konflikt  | daemon.json + systemctl restart     | ❌ RAM-OOM + unklar |
+| **v6**  | RAM-OOM + Daemon-Neustart komplex  | **config.json direkt + max-parallel:1** | ✅ erwartet grün |
 
 ---
 
@@ -151,6 +152,63 @@ Pull-Traffic ist klein (Metadata + Layer-Hashes), nur der Push war das Problem.
 
 ---
 
+## Fix v6: config.json direkt schreiben — die finale Lösung ✅
+
+### Zwei Probleme behoben
+
+**Problem 1 — RAM-OOM:** 4 Matrix-Jobs liefen parallel auf einem 16 GB Runner.
+Jeder Job: Gradle-Build + Docker-Buildx = leicht 3–4 GB. Zusammen → 15+ GB → OOM → Builds crashed.
+
+**Problem 2 — Daemon-Interaktion:** Alle bisherigen Ansätze versuchten den Docker-Daemon zu
+konfigurieren (`daemon.json`, `systemctl`, `iptables`). Der Daemon ist aber ein systemd-Service
+auf der VM — nicht derselbe Prozess wie buildkitd (der eigentliche Push-Agent).
+
+### Lösung
+
+```yaml
+# Schritt 1: Credentials OHNE Daemon-Kontakt schreiben
+- name: Registry-Credentials konfigurieren (kein Daemon-Kontakt)
+  run: |
+    mkdir -p ~/.docker
+    AUTH=$(echo -n "${{ secrets.REGISTRY_USER }}:${{ secrets.REGISTRY_TOKEN }}" | base64 -w 0)
+    printf '{"auths":{"%s":{"auth":"%s"}}}\n' "10.0.0.22:3000" "${AUTH}" > ~/.docker/config.json
+
+# Schritt 2: BuildKit mit HTTP/insecure für interne Registry
+- name: Set up Docker Buildx
+  uses: docker/setup-buildx-action@v3
+  with:
+    config-inline: |
+      [registry."10.0.0.22:3000"]
+        http = true
+        insecure = true
+```
+
+```yaml
+# RAM-Schutz: sequenziell statt parallel
+strategy:
+  max-parallel: 1
+```
+
+**Warum das funktioniert:**
+- `printf ... > ~/.docker/config.json` — schreibt Credentials direkt, kein Registry-Ping, kein Daemon
+- buildkitd liest `~/.docker/config.json` beim Push automatisch
+- `config-inline` konfiguriert buildkitd (nicht den Daemon) auf HTTP für `10.0.0.22:3000`
+- `max-parallel: 1` — sequenzielle Jobs, kein RAM-OOM mehr möglich
+
+**Traffic-Weg v6:**
+```
+Workflow schreibt ~/.docker/config.json (kein Netzwerk)
+      ↓
+BuildKit (buildkitd Container) startet
+      ↓ liest config.json für Auth
+      ↓ config-inline: http=true für 10.0.0.22:3000
+BuildKit push → http://10.0.0.22:3000 → Gitea (intern, kein Pangolin)
+```
+
+Kein sudo. Kein systemctl. Kein socat. Kein iptables. Kein Neustart.
+
+---
+
 ## Gelernt
 
 - Minimale Runner-Images haben oft kein `socat` — APT-Repos auf Air-Gapped Systemen sind limitiert