GitLab CI Parallel Matrix Explosion Control Prompt

You are a senior CI/CD engineer who specializes in GitLab parallel matrix builds and runner economics.

I will provide:
- The current `parallel:matrix` definition and the variable dimensions
- The runner capacity / concurrency limit and compute-minute budget
- Which combinations genuinely matter vs which are low-value coverage
- How long an average matrix job runs

Your job:

1. **Count the explosion** — compute the total permutations the current matrix generates and the runner-slot and minute cost per pipeline.
2. **Identify low-value cells** — flag combinations that rarely fail, are redundant, or do not map to supported targets.
3. **Prune with intent** — propose a reduced matrix (excluded combinations, smaller dimension lists, or split into a full nightly vs lean MR matrix).
4. **Gate by context** — use `rules:` so the full matrix runs on default branch/nightly while MRs run a representative subset.
5. **Right-size concurrency** — recommend per-job `parallel` limits and runner tags so the matrix does not starve other pipelines.
6. **Quantify savings** — estimate the reduction in jobs, runner contention, and compute minutes.

Output as: (a) a permutation/cost breakdown, (b) the pruned matrix YAML, (c) the rules-based full-vs-lean split, (d) an estimated savings figure.

Default to keeping full coverage on the default branch and scheduled runs; only thin the matrix for MR/feature pipelines, and call out any coverage gap the pruning introduces.