Geteilte Docker-Build-and-Push-Pipeline anlegen

Die bisher in einem einzelnen Projekt liegende Pipeline zieht als
wiederverwendbarer Workflow (on: workflow_call) nach
.gitea/workflows/docker-build-push.yml um.

Inhaltlich geaendert ist genau eine Stelle: Der Eigentuemer des Images
stand als IMAGE_OWNER fest im env-Block des Workflows, wodurch jedes
Image jedes aufrufenden Projekts unter git.jk-dev.de/suer/... gelandet
waere. Er ist jetzt die Eingabe image-owner mit suer als Vorgabewert,
sodass bestehende Aufrufer unveraendert weiterlaufen.

Der Wert kann nicht im env-Block bleiben: env auf Workflow-Ebene wird
ausgewertet, bevor es einen inputs-Kontext gibt. Die Tag-Liste liest ihn
deshalb unmittelbar aus inputs.

Alles Uebrige ist unveraendert uebernommen, samt der Kommentare, die das
Warum erklaeren: 1Password Connect, runs-on, DOCKER_HOST, Diagnoseschritt,
Multi-Arch und Tag-Schema.

Die README dokumentiert Eingaben, ein vollstaendiges Aufrufbeispiel, die
Voraussetzungen im aufrufenden Repository und den Hinweis, auf einen Tag
statt auf @main zu zeigen.

README.md

@@ -1 +1,92 @@
-# Hier stehen wichtige Infos!
+# pipelines
+
+Geteilte CI/CD-Bausteine für die Gitea-Instanz `git.jk-dev.de`. Die Workflows
+hier werden nicht selbst ausgelöst, sondern von anderen Repositories über
+`uses:` aufgerufen (`on: workflow_call`).
+
+## Bausteine
+
+### `.gitea/workflows/docker-build-push.yml`
+
+Baut ein Docker-Image und schiebt es als Multi-Arch-Manifest
+(`linux/amd64,linux/arm64`) in die Registry `git.jk-dev.de`. Läuft auf einem
+Runner mit dem Label `ubuntu-docker`.
+
+Gepusht wird unter fünf Tags:
+
+```
+git.jk-dev.de/<image-owner>/<container-name>:latest
+git.jk-dev.de/<image-owner>/<container-name>:<version-number>
+git.jk-dev.de/<image-owner>/<container-name>:<major>
+git.jk-dev.de/<image-owner>/<container-name>:<major>.<minor>
+git.jk-dev.de/<image-owner>/<container-name>:<major>.<minor>.<patch>
+```
+
+Der Checkout holt Submodule mit; die Zugangsdaten dafür und für die Registry
+kommen zur Laufzeit aus 1Password Connect.
+
+#### Eingaben
+
+| Eingabe                | Pflicht | Vorgabe                   | Bedeutung |
+| ---------------------- | ------- | ------------------------- | --------- |
+| `version-number`       | ja      | —                         | Vollständige Version, wird als Tag gesetzt |
+| `version-number-major` | ja      | —                         | Major-Anteil für die mitwandernden Tags |
+| `version-number-minor` | ja      | —                         | Minor-Anteil |
+| `version-number-patch` | ja      | —                         | Patch-Anteil |
+| `container-name`       | ja      | —                         | Name des Images |
+| `dockerfile`           | ja      | —                         | Pfad zum Dockerfile |
+| `docker-context`       | ja      | —                         | Build-Kontext |
+| `image-owner`          | nein    | `suer`                    | Eigentümer-Segment des Images, also der mittlere Teil von `<registry>/<owner>/<name>` |
+| `timeout-minutes`      | nein    | `45`                      | Harte Grenze für den Build-Job |
+| `platforms`            | nein    | `linux/amd64,linux/arm64` | Zielplattformen der Manifest-Liste |
+| `build-args`           | nein    | —                         | Zusätzliche Build-Argumente, ein `NAME=wert` je Zeile |
+
+#### Aufrufbeispiel
+
+```yaml
+jobs:
+  image:
+    uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@v1
+    with:
+      version-number: 2026.09.1
+      version-number-major: '2026'
+      version-number-minor: '09'
+      version-number-patch: '1'
+      container-name: bk-dev-website
+      dockerfile: ./Dockerfile
+      docker-context: .
+      image-owner: bekemeyer-klein
+    secrets: inherit
+```
+
+`secrets: inherit` ist notwendig — der Workflow braucht `OP_CONNECT_TOKEN` aus
+dem aufrufenden Repository.
+
+#### Voraussetzungen im aufrufenden Repository
+
+| Name               | Art      | Zweck |
+| ------------------ | -------- | ----- |
+| `OP_CONNECT_HOST`  | Variable | Adresse des 1Password-Connect-Servers im Cluster |
+| `OP_CONNECT_TOKEN` | Secret   | Zugang zu diesem Connect-Server |
+| `DOCKER_HOST`      | Variable | Nur nötig, wenn der Runner-Daemon rootless läuft und sein Socket nicht unter `/var/run/docker.sock` liegt (dann z. B. `unix:///run/user/1000/docker.sock`). Ist die Variable nicht gesetzt, nutzt Docker seinen Default. |
+
+Die eigentlichen Zugänge für Checkout und Registry liegen in 1Password
+(`GitHub-Actions/jlab-git-checkout-token`, `GitHub-Actions/jlab-registry-access`)
+und müssen in Gitea nicht hinterlegt werden.
+
+## Auf einen Tag zeigen, nicht auf `@main`
+
+Aufrufe bitte immer an einen Tag binden:
+
+```yaml
+uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@v1   # so
+uses: workflow-util/pipelines/.gitea/workflows/docker-build-push.yml@main # nicht so
+```
+
+Mit `@main` ändert jede Anpassung hier unangekündigt das Verhalten sämtlicher
+Projekte — und der Fehler zeigt sich dann dort, wo niemand etwas geändert hat.
+Ein Tag macht das Übernehmen einer neuen Fassung zu einer bewussten Entscheidung
+im jeweiligen Projekt.
+
+Änderungen hier bekommen deshalb einen neuen Tag. Bricht eine Änderung
+bestehende Aufrufe, wird der Major-Anteil erhöht.