[SIMPL-30451] Point image references at the project registry path

The GitLab project lives at simpl-open/data/supporting-data-services/distributed-execution/distributed-execution, so CI_REGISTRY_IMAGE ends in the project name twice. The pipeline pushes to CI_REGISTRY_IMAGE and nowhere else, so the earlier one-segment path named an image nobody builds - the same mismatch that field-level-pseudo-anonymisation and dataframe-level-anonymisation carry today.

Changelog: fixed

src/distributed_execution/loosely_coupled/jobs.py

@@ -38,7 +38,8 @@ PAYLOAD_SCRIPT = os.environ.get("PIPES_PAYLOAD_SCRIPT", str(_REPO_ROOT / "payloa
 
 PAYLOAD_IMAGE = os.environ.get(
     "PIPES_PAYLOAD_IMAGE",
-    "code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution/payload:0.1.0",
+    "code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services"
+    "/distributed-execution/distributed-execution/payload:0.0.1",
 )
 PAYLOAD_NAMESPACE = os.environ.get("PIPES_PAYLOAD_NAMESPACE", "dagster")
 

yaml/loosely-coupled/values-pipes-payload.yaml

@@ -6,6 +6,19 @@
 # Contrast with yaml/tightly-coupled/values-run-launcher.yaml: there, every
 # execution pod needed S3 and Vault credentials. Here the payload needs none -
 # only the dispatching pod does.
+#
+# VERSION LOCK. The payload tag below must equal the code location image tag in
+# yaml/values-dagster-distributed-execution.yaml. The two images share a commit:
+# the dispatching op and payload/work.py agree on the `units` extras key and on
+# the custom-message shape, and nothing at runtime checks that agreement. A
+# mismatched pair surfaces as "no pipes messages received", which reads like a
+# broken message channel rather than a version skew.
+#
+# For values that work today, see yaml/sandbox/values-sandbox-gitea.yaml. The
+# shared GitLab pipeline (ds.gitlab-ci.yml) builds exactly one image per project -
+# $CI_REGISTRY_IMAGE from the root Dockerfile - so the payload reference below
+# resolves only once that pipeline learns to build a second image. The Gitea
+# workflow in .gitea/workflows/docker-publish.yml already builds both.
 
 dagster:
   dagster-user-deployments:
@@ -14,7 +27,8 @@ dagster:
         envSecrets: []
         env:
           - name: PIPES_PAYLOAD_IMAGE
-            value: code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution/payload:0.1.0
+            # DO NOT CHANGE the tag - replaced automatically by the pipeline before releasing
+            value: code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution/distributed-execution/payload:0.0.0
           - name: PIPES_PAYLOAD_NAMESPACE
             value: dagster
 
@@ -27,6 +41,7 @@ dagster:
           containerConfig:
             env:
               - name: PIPES_PAYLOAD_IMAGE
-                value: code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution/payload:0.1.0
+                # DO NOT CHANGE the tag - replaced automatically by the pipeline before releasing
+                value: code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution/distributed-execution/payload:0.0.0
               - name: PIPES_PAYLOAD_NAMESPACE
                 value: dagster

yaml/values-dagster-distributed-execution.yaml

@@ -28,7 +28,9 @@ dagster:
 
         image:
           pullPolicy: IfNotPresent
-          repository: code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution
+          # $CI_REGISTRY_IMAGE for this project - the pipeline pushes here, so anything
+          # else is a reference to an image nobody builds.
+          repository: code.europa.eu:4567/simpl/simpl-open/data/supporting-data-services/distributed-execution/distributed-execution
           tag: 0.0.0 # DO NOT CHANGE - replaced automatically by the pipeline before releasing
 
         port: 4000