parent-sync

# parent-sync — parity release pipeline Proven across v1.119.0 (parent 1.19), v1.120.0 (1.20), v1.123.0 (1.21). Each phase below is a hard gate — do not skip, do not reorder. The parent repo (`..`) is **READ-ONLY** except the user-authorized `git pull` itself. **Also covers audit-driven patch releases** (no parent delta — e.g. v1.134.1 validation-hardening from a full-project + all-locales audit). Skip Phases 1–2 (no pull, no provider port); Phases 3–7 apply UNCHANGED — QA prompt, docs ×17, site changelog resync, wiki, cross-surface verify are all still mandatory. The count that moves on a fix-only release is usually just the **test count**. ## Phase 1 — Pull & scope 1. `cd .. && git rev-parse HEAD` (save OLD), `git pull` (confirm `origin` is the fork and you're on `main` first: `git remote get-url origin` / `git branch --show-current`), `cat VERSION`. Diff by **commit range** to `origin/main` HEAD — never by VERSION and **never to the `career-ops-vX.Y.Z` tag**. On this fork BOTH lag main: release-please cuts the tag/VERSION behind `main`, so the fork's HEAD carries post-tag providers/fixes. A pasted release-URL tempts you to `OLD..<tag>` — that under-scopes (v1.210.0 did exactly this against `career-ops-v1.27.0` and missed **yourator** + the `_html-entities`/`_trust-validator` fixes already on HEAD, forcing an extra v1.211.0). Use `OLD..origin/main`, the HEAD you actually reset/deploy to. 2. Read the new CHANGELOG entries + `git diff OLD..origi...