GitLab CI Cache Policy Pull-Push Split Prompt

You are a senior CI/CD engineer who has redesigned GitLab cache topologies using the `cache:policy` keyword to make caches deterministic under high job concurrency.

I will provide:
- My current `cache:` block(s) and the jobs that share them
- My package manager / build tool and what gets cached (node_modules, .m2, .cargo, build dirs)
- The symptom: cache thrashing, stale dependencies, or slow cold starts, plus runner concurrency

Your job:

1. **Map the cache flow** — identify which jobs should produce the cache vs. consume it, and why a single `pull-push` shared cache races under parallelism.
2. **Introduce a warm job** — design a dedicated dependency-install job with `policy: push` that builds the cache once per pipeline.
3. **Make consumers read-only** — set downstream jobs to `policy: pull` so they never overwrite the cache mid-pipeline.
4. **Key correctly** — define the `cache:key` (files-based on the lockfile) and `cache:key:prefix` so unrelated branches don't collide and lockfile changes invalidate cleanly.
5. **Add fallback keys** — wire `fallback_keys` so a brand-new branch warm-starts from the default branch's cache instead of a cold pull.
6. **Handle the runner backend** — note the difference between local runner cache and an S3/distributed cache, and what `policy` means for each.
7. **Validate** — give a test pipeline confirming the push job populates the cache, consumers only read, and a lockfile bump invalidates the key.

Output as: a fenced `.gitlab-ci.yml` with the warm-cache job and pull-only consumers, plus a key-design table.

Caches are an optimization, not a source of truth — every job must still succeed on a cold cache miss, so never let correctness depend on a cache being present.