[SIMPL-30451] Add sandbox deployment values and the pull-secret caveat

yaml/sandbox/values-sandbox-gitea.yaml carries the registry coordinates, the pull secret both namespaces need, and the commit SHA the two images share. The sandbox registry rejects anonymous pulls, so a payload namespace without its own pull secret leaves the dispatching op waiting on a pod that never starts - readiness check L4 now says so.

Changelog: added

documents/user-guide/distributed-execution-guide.md

@@ -395,6 +395,7 @@ setting. There is no UI control that switches a workflow between the two pattern
 | `yaml/tightly-coupled/values-run-launcher.yaml` | Run launcher type, namespace, pod env |
 | `yaml/tightly-coupled/rbac-step-executor.yaml` | Permissions required by `k8s_job_executor` |
 | `yaml/loosely-coupled/values-pipes-payload.yaml` | Payload image reference and target namespace |
+| `yaml/sandbox/values-sandbox-gitea.yaml` | Sandbox registry coordinates, pull secret, and the SHA both images share |
 | `yaml/loosely-coupled/rbac-pipes-dispatch.yaml` | Permissions required by the dispatching pod |
 | `yaml/values-dagster-distributed-execution.yaml` | Code location image and entry point |
 
@@ -515,6 +516,7 @@ Tracked under SIMPL-30451.
 | Both images build; payload image passes the isolation check (L11) | Tech details | Complete |
 | Locally runnable jobs launched from the Dagster UI, evidence recorded in section 5.6 | Tech details | Complete |
 | Payload image published to a container registry | Tech details | Complete on the sandbox Gitea registry; the GitLab registry still pending |
+| GitLab pipeline builds both images | Tech details | **Pending** — the shared `ds.gitlab-ci.yml` template builds one image from the root Dockerfile |
 | End-to-end run of `loosely_coupled_k8s_job` on a cluster | Tech details | **Pending** |
 | Screenshots of UI surfaces | Tech details | **Pending** — needs a deployed platform instance, not a local dev server |
 | Platform architecture document update | Tech details | **Pending** |

documents/user-guide/readiness-checklist.md

@@ -46,7 +46,7 @@ location image.
 | L1 | Payload contract is intact | `uv run pytest tests/test_loosely_coupled.py` | `test_payload_does_not_import_dagster` passes — the payload imports `dagster_pipes` only |
 | L2 | Pipes round trip works | Launch `loosely_coupled_subprocess_job` | Run reaches `SUCCESS`; run logs contain the payload's `External payload started on …` line, proving `pipes.log` crossed the channel |
 | L3 | Silence is treated as failure | Same test module | `test_silent_message_path_is_treated_as_failure` passes — an empty message list raises rather than yielding an empty result |
-| L4 | Payload image is pullable by the target cluster | `kubectl -n <payload-ns> run pull-probe --image=<payload-image> --restart=Never --command -- true` | Pod reaches `Completed`; no `ImagePullBackOff` |
+| L4 | Payload image is pullable by the target cluster | `kubectl -n <payload-ns> run pull-probe --image=<payload-image> --restart=Never --command -- true` | Pod reaches `Completed`; no `ImagePullBackOff`. The sandbox Gitea registry rejects anonymous pulls, so the payload namespace needs its own pull secret — see `yaml/sandbox/values-sandbox-gitea.yaml` |
 | L5 | Dispatcher can create Jobs in the payload namespace | `kubectl -n <payload-ns> auth can-i create jobs --as=system:serviceaccount:dagster:dagster-dev` | Returns `yes` |
 | L6 | Dispatcher can read pod logs — **the message channel** | `kubectl -n <payload-ns> auth can-i get pods/log --as=system:serviceaccount:dagster:dagster-dev` | Returns `yes`. A `no` here breaks reporting *without* failing the workload |
 | L7 | Payload Job is actually created | Launch `loosely_coupled_k8s_job`, then `kubectl -n <payload-ns> get jobs -l app.kubernetes.io/name=distributed-execution-payload` | One Job per dispatch, labelled `dagster/execution-target=loosely-coupled` |