Passe das Script

  ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

so an, dass es das Script

  ./jenkins-ci-rme/jenkins_builder_ubuntu26.sh

innerhalb des von `new_docker_build.sh` gebauten bzw. verwendeten Docker-Images ausführt.

Kontext:
- Script A:
  ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

- Script B:
  ./jenkins-ci-rme/jenkins_builder_ubuntu26.sh

- Script C:
  ./rpmbuild/make_rpm_ubuntu26.py

- Script B ruft Script C auf, um RPM- und DEB-Pakete zu erzeugen.
- Das Docker-Image, das von Script A gebaut oder verwendet wird, soll alle notwendigen Tools enthalten, damit Script B und Script C erfolgreich laufen.
- Die erzeugten RPM-/DEB-Pakete sollen nach dem Docker-Lauf auf dem ausführenden Host verfügbar sein, z. B. über einen bind mount / Ausgabe-Mountpunkt.

Gewünschte Änderungen:

1. Neue Option in Script A hinzufügen
   - Füge eine neue CLI-Option hinzu, z. B.:

     --run-jenkins-builder

   - Wenn diese Option gesetzt ist, soll Script A nach dem Docker-Image-Build bzw. beim Docker-Run das Script B innerhalb des Docker-Containers ausführen.

2. Ausgabe-Mountpunkt hinzufügen
   - Füge eine Option hinzu, z. B.:

     --package-output-dir <path>

   - Dieser Pfad liegt auf dem Host.
   - Der Pfad soll beim Docker-Run in den Container gemountet werden.
   - Die von Script B/C erzeugten RPM-/DEB-Pakete sollen anschließend dort verfügbar sein.
   - Falls kein Pfad angegeben wird, verwende einen sinnvollen Default, z. B.:

     ./packages-out

3. Docker-Image erweitern
   - Stelle sicher, dass im Docker-Image alle Tools installiert sind, die für Script B und C benötigt werden.
   - Analysiere dazu:
     - ./jenkins-ci-rme/jenkins_builder_ubuntu26.sh
     - ./rpmbuild/make_rpm_ubuntu26.py
     - ggf. vorhandene Dockerfiles oder Paketlisten
   - Installiere fehlende Tools im Image, z. B. je nach Bedarf:
     - python3
     - python3-pip
     - rpm/rpmbuild
     - debhelper
     - dpkg-dev
     - fakeroot
     - build-essential
     - git
     - cmake
     - ninja-build
     - qt6-related packages
     - sonstige tatsächlich benötigte Abhängigkeiten

4. Docker-Ausführung
   - Wenn `--run-jenkins-builder` gesetzt ist, soll Script A den Container so starten, dass:
     - das Repository bzw. der relevante Workspace im Container verfügbar ist
     - Script B im Container ausgeführt wird
     - der Paket-Ausgabeordner vom Host in den Container gemountet wird
     - am Ende die erzeugten `.rpm` und `.deb` Dateien auf dem Host sichtbar sind
Zusätzliche Anforderungen zu Umgebungsvariablen:

Script A benötigt für den neuen Ablauf folgende Variablen:

  PROJECT          LTS flavor: qatar | ahtc | guez (cmake -D_pname)
  OS_VERSION       Ubuntu version, e.g. 26.04
  LTS_VERSION      Major.minor LTS version, e.g. 1.0
  GUEZ_MODE        ON | OFF — cmake -DGUEZ_MODE
  WORKSPACE        Jenkins workspace path, normally set automatically by Jenkins
  PROJECT_BASE_DIR Path used by make_rpm_ubuntu26.py as the source tree
  BUILD_NUMBER     Jenkins build number, used as release in DEB version
  BUILD_TAG        Jenkins build tag

Für den Docker-Aufruf aus Script A sollen mindestens diese Werte gesetzt bzw. in den Container übergeben werden:

  PROJECT=guez
  GUEZ_MODE=ON
  PROJECT_BASE_DIR="${MIGRATE_PIPELINE_ROOT}/qt-migration-legatus/qt6-after/qt6-migrated-legatus"

Die übrigen benötigten Variablen sollen robust bestimmt oder sinnvoll gesampelt werden, falls sie außerhalb von Jenkins nicht gesetzt sind:

  OS_VERSION:
    - wenn möglich aus dem Docker-Image bzw. Container bestimmen, z. B. über /etc/os-release
    - erwarteter Wert für Ubuntu 26.04: 26.04

  LTS_VERSION:
    - falls nicht gesetzt, sinnvollen Default verwenden, z. B. 1.0
    - optional als CLI-Option überschreibbar machen

  WORKSPACE:
    - falls nicht gesetzt, auf den Repository-/Arbeitsverzeichnis-Pfad im Container setzen

  BUILD_NUMBER:
    - falls nicht gesetzt, auf einen lokalen Default setzen, z. B. 0 oder 1
    - wichtig: Wert muss für make_rpm_ubuntu26.py verwendbar sein

  BUILD_TAG:
    - falls nicht gesetzt, aus PROJECT, BUILD_NUMBER und lokalem Kontext erzeugen, z. B.
      local-${PROJECT}-${BUILD_NUMBER}

Die Variablen sollen beim Docker-Run explizit mit `-e` in den Container übergeben werden, damit `jenkins_builder_ubuntu26.sh` und `make_rpm_ubuntu26.py` dieselbe Umgebung sehen wie in Jenkins.

Beispielhafte Übergabe:

  -e PROJECT=guez
  -e GUEZ_MODE=ON
  -e OS_VERSION="${OS_VERSION}"
  -e LTS_VERSION="${LTS_VERSION}"
  -e WORKSPACE="${CONTAINER_WORKSPACE}"
  -e PROJECT_BASE_DIR="${PROJECT_BASE_DIR}"
  -e BUILD_NUMBER="${BUILD_NUMBER}"
  -e BUILD_TAG="${BUILD_TAG}"

Akzeptanzkriterium zusätzlich:
- Beim neuen Ablauf mit `--run-jenkins-builder` sind alle oben genannten Variablen im Container gesetzt.
- `PROJECT`, `GUEZ_MODE` und `PROJECT_BASE_DIR` haben die vorgegebenen Werte.
- Die restlichen Werte werden entweder aus der vorhandenen Umgebung übernommen, aus dem Docker-Image/Container bestimmt oder mit nachvollziehbaren lokalen Defaults gesetzt.

5. Robustheit
   - Prüfe, ob Script B existiert und ausführbar ist.
   - Falls nötig, setze executable permissions oder rufe es explizit mit `bash` auf.
   - Prüfe, ob der Ausgabeordner existiert; falls nicht, erstelle ihn.
   - Verwende absolute Pfade für Docker volume mounts.
   - Brich bei Fehlern mit aussagekräftigen Fehlermeldungen ab.
   - Verwende `set -euo pipefail`, sofern passend und noch nicht vorhanden.
   - Bestehendes Verhalten von Script A darf ohne die neue Option nicht verändert werden.

6. Dokumentation
   - Aktualisiere ggf. vorhandene README- oder Hilfetexte.
   - Die Usage-Ausgabe von Script A soll die neuen Optionen beschreiben.

7. Tests / Validierung
   - Führe soweit möglich ShellCheck oder eine vergleichbare Prüfung für geänderte Shell-Scripts aus.
   - Prüfe mindestens syntaktisch:
     - Script A
     - Script B
   - Wenn möglich, teste den neuen Ablauf mit:
     
     ./qt-migration-legatus/qt6-after/qt6-migrated-legatusnew_docker_build.sh --run-jenkins-builder --package-output-dir ./packages-out

Akzeptanzkriterien:
- Script A hat eine neue Option zum Ausführen von Script B im Docker-Container.
- Script B läuft innerhalb des Docker-Images D, das durch Script A gebaut/verwendet wird.
- Script C wird über Script B ausgeführt.
- Das Docker-Image enthält alle notwendigen Build- und Packaging-Tools.
- Die erzeugten RPM-/DEB-Pakete sind nach Ende des Laufs auf dem Host unter dem angegebenen Ausgabeordner verfügbar.
- Ohne neue Option bleibt das bisherige Verhalten von Script A unverändert.
- Änderungen sind nachvollziehbar, robust und dokumentiert.