[SIMPL-30451] Verify the Kubernetes pipes transport on the sandbox

Run cff9b348-bfc3-4ac1-ab51-a94892b8e3a0 of loosely_coupled_k8s_job reached RUN_SUCCESS in dataprovider01 on sandbox-cat-dat: four payload Jobs, four distinct payload pod hostnames in contributing_hosts, and the payload log lines in the run log. Checks L4-L10 are now observed rather than derived. Torn down afterwards; the namespace was left as it was found.

Corrects two claims that were wrong. The registry does NOT require a pull secret - a bare GET returns 401, but that is the opening move of the Docker token handshake, and completing it anonymously returns the manifest for both images. And PIPES_PAYLOAD_NAMESPACE was set to a namespace named dagster, which does not exist on that cluster; the release is called dagster but runs in dataprovider01.

Adds the sandbox probe variant. The generic probe cannot run there: sandbox access is Rancher project-scoped, so a new namespace grants its creator nothing and Role creation is denied everywhere. It is not needed either, since dagster-role already carries the exact pipes permissions.

Changelog: added

yaml/sandbox/values-sandbox-gitea.yaml

@@ -1,8 +1,9 @@
 # Sandbox deployment values - Gitea registry.
 #
-# NOT CLUSTER-VERIFIED. These values are written against images that exist and a
-# registry whose auth behaviour was checked, but they have not been applied to a
-# Simpl cluster. Confirm and amend after the first deployment.
+# NOT CLUSTER-VERIFIED. The images and the registry behaviour here are confirmed
+# - a probe pod ran from them on the sandbox on 2026-08-31 - but these values
+# have never been applied as a code location. Registering this service against
+# the sandbox Dagster is still blocked on the version skew below.
 #
 # VERSION SKEW, unresolved. These images carry dagster 1.13.19 (requirements.txt
 # pins no upper bound, so the build took whatever was current). The sandbox
@@ -21,39 +22,18 @@
 # the version lock: the code location and the payload it dispatches must come
 # from one commit. Bump both together or not at all.
 #
-# The sandbox Gitea registry requires authentication - an anonymous manifest GET
-# returns 401 - so a pull secret is required in every namespace that pulls either
-# image. Create it with a Gitea access token that has read:package scope:
+# The Gitea images are anonymously pullable, so NO pull secret is needed. A bare
+# GET to the registry returns 401, which reads as a refusal but is only the start
+# of the Docker token handshake; completing it anonymously and re-requesting the
+# manifest returns 200 for both images. This was confirmed on 2026-08-31, and a
+# probe pod carrying no credentials pulled and ran on the sandbox.
 #
-#   kubectl -n <namespace> create secret docker-registry gitea-registry \
-#     --docker-server=gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu \
-#     --docker-username=<gitea-user> \
-#     --docker-password=<gitea-token>
-#
-# The payload namespace needs it too: PipesK8sClient creates that Job, and a
-# missing pull secret there leaves the op waiting on a pod that never starts,
-# which surfaces as pod_wait_timeout rather than as an image error.
-#
-# PULL SECRET PLACEMENT. Checked against the chart templates in dagster 1.12.8,
-# which is what the sandbox runs. There is no per-deployment imagePullSecrets
-# field - deployment-user.yaml reads the SUBCHART value and the run launcher
-# helper reads the PARENT value - so a pull secret nested under a deployments[]
-# entry is silently discarded, and the pod fails with ImagePullBackOff against a
-# values file that looks correct.
-#
-# Both keys below therefore apply to every code location in the release, not
-# just this one. Extra pull secrets are ignored for registries they do not match,
-# so the existing code locations are unaffected.
+# An earlier revision of this file required a pull secret on both the deployment
+# and the run launcher. That was wrong, and wrong in an expensive direction: it
+# sent the reader looking for credentials that do not exist.
 
 dagster:
-  # Run pods, webserver and daemon.
-  imagePullSecrets:
-    - name: gitea-registry
-
   dagster-user-deployments:
-    # Code server pods.
-    imagePullSecrets:
-      - name: gitea-registry
     deployments:
       - name: distributed-execution
         image:
@@ -63,8 +43,10 @@ dagster:
         env:
           - name: PIPES_PAYLOAD_IMAGE
             value: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution-payload:5122da4691f9
+          # The sandbox release is named `dagster` but lives in dataprovider01;
+          # there is no namespace called `dagster` on that cluster.
           - name: PIPES_PAYLOAD_NAMESPACE
-            value: dagster
+            value: dataprovider01
 
   runLauncher:
     config:
@@ -75,4 +57,4 @@ dagster:
               - name: PIPES_PAYLOAD_IMAGE
                 value: gitea.dataprovider01.sandbox-cat-dat.simpl-europe.eu/j.r/distributed-execution-payload:5122da4691f9
               - name: PIPES_PAYLOAD_NAMESPACE
-                value: dagster
+                value: dataprovider01