Tell downstream pipelines which image repositories to use

.trigger-downstream-pipeline-ref tells downstream pipelines which ref and which short SHA to test, but not which container repository the images for that SHA were pushed to. That is this project's release policy: development docker images publishes to gitlab-runner-dev / gitlab-runner-helper-dev from merge request pipelines only, while bleeding edge docker images and stable docker images publish to $CI_REGISTRY_IMAGE and $CI_REGISTRY_IMAGE/gitlab-runner-helper. With nothing in the contract saying which, gitlab-org/ci-cd/tests/runner-incept hardcoded the dev repositories, so the v19.3.0 trigger pulled gitlab-runner-dev:alpine-9cbf0074 (404) instead of gitlab-org/gitlab-runner:alpine-9cbf0074 (200) and its runner pod sat in ImagePullBackOff: https://gitlab.com/gitlab-org/ci-cd/tests/runner-incept/-/jobs/15985719873

The tag was never the problem: make print_image_tags always emits the short SHA, so all three release jobs publish it and only the repository varies. So this adds two variables, defaulted to the canonical repositories at job level and overridden to the dev ones on the three merge_request_event rules. Both derive from $CI_REGISTRY_IMAGE rather than being written out, so they cannot drift from the pusher invocations in release.gitlab-ci.yml.

Values are full repository paths including the registry host, so no separate registry variable is needed. The consumer passes the whole path to the Helm chart's image.image with image.registry empty, which the chart's gitlab-runner.image helper handles by omitting the prefix.

gitlab-org/ci-cd/tests/runner-incept!79 (merged) reads both variables and falls back to deriving them from a refs/merge-requests/ prefix on UPSTREAM_CI_COMMIT_REF when they are absent, so the two can merge in either order.

Checked with POST /ci/lint on the merged config that all four jobs extending the anchor carry the new variables and that the dev overrides land on exactly the three merge request rules. This MR's own pipeline exercises the dev path; the tag path cannot be exercised before a release, which is why the values are $CI_REGISTRY_IMAGE-derived rather than literal.

Unrelated defect this turned up

package test variables and trigger runner package tests extend this anchor and then list .rules:release:bleeding-edge, which replaces the rules list wholesale rather than merging it, so they lose every rule-level UPSTREAM_CI_COMMIT_REF override and keep the job-level $CI_COMMIT_BRANCH. That is empty on tag pipelines, and those rules do run on vX.Y.Z-rcN tags, so on every RC trigger runner package tests forwards an empty ref to gitlab-runner-package-tests, whose .gitlab-ci.yml uses ref: $UPSTREAM_CI_COMMIT_REF for a cross-project artifact fetch. It stays invisible because that trigger also has strategy: depend commented out. Not touched here, and the two new variables are ref-independent so they are correct in both jobs. Issue to follow.