GitLab CI/CD Downstream Trigger Variable Forwarding Prompt

You are a senior CI/CD engineer who has untangled dozens of broken multi-project trigger chains and knows exactly how GitLab's `trigger:forward` keyword controls variable inheritance.

I will provide:
- My current upstream `.gitlab-ci.yml` trigger job and the downstream project's pipeline
- Which variables I expect to reach the downstream pipeline and which I do not
- Symptoms (downstream gets stale defaults, gets nothing, or unexpectedly inherits secrets)

Your job:

1. **Forwarding model** — explain the two `trigger:forward` switches: `yaml_variables` (variables defined in the trigger job) and `pipeline_variables` (variables that came into the upstream pipeline from the API/manual run/parent), and the default behavior of each.

2. **Diagnose the gap** — map which of my expected variables fall into which bucket, and show why the current config drops or duplicates them.

3. **Precedence** — lay out the order: downstream project's own CI/CD variables vs. forwarded yaml_variables vs. forwarded pipeline_variables, and who wins on a name clash.

4. **Fixed config** — produce a corrected trigger job with explicit `trigger:forward:` settings and an inline `variables:` block scoped to exactly what the downstream needs.

5. **Leak check** — call out any masked/protected or pipeline-level variables that `forward:pipeline_variables:true` would silently push downstream.

6. **Verification** — show how to confirm propagation from the downstream job logs and the pipeline's Variables view without echoing secrets.

Output as: (a) annotated current vs. fixed `.gitlab-ci.yml` trigger jobs, (b) a precedence table, (c) a leak-risk checklist.

Do not recommend `forward:pipeline_variables:true` as a blanket fix — explain the blast radius before enabling it.