PROD-2782: republish a page's other locale when a save in one locale puts it in staging

[5PK]

Stacked on #236 (PROD-2773) → #235 → #234. Merge those first; this PR's diff is against #236's branch.

Problem

A page's zones are shared by all of its locales. When the CLI saves a page in one locale and the save adds, removes or reorders components, the server puts the page in Staging in its other locales:

• ClearPageContent and ReorderPageContent cut a new page version.
• They give every language linked to the old version a new ContentItems row in state 1.

A field-only save (UpdatePageItem) carries the other languages' rows over unchanged, so it doesn't do this.

--autoPublish only republished pages the run saved in that locale, so the other locale stayed in Staging. The PROD-2628 refresh then recorded its new version as in sync, so later runs skipped it as up to date and never fixed it. The live site is unaffected, but the target no longer matches the source: the page is Published there and Staging here, and that locale's live page doesn't pick up the new structure.

This mostly shows up when the target's structure changes without a matching source change in the other locale:

• repairing a damaged target, such as restoring components removed by PROD-2776
• the other locale was skipped in the run
• the CLI changed the structure itself (PROD-2316 drops, a first sync)

Change

• refreshOtherLocaleVersions already re-reads the page in every other locale of the run after a save. It now records the page for republishing in that locale when all of these hold:
  • it was Published on the target when the run pulled it
  • it is Staging now
  • it is Published on the source (a page left in staging on the source stays in staging)
  • the record was in sync before the save (unchanged: an independent target edit still conflicts and isn't touched)
• executeAutoPublish (pages / both) adds those pages to that locale's publish list. Duplicates are removed by the existing per-locale de-duplication, and the existing updateMappingsAfterPublish moves their mapping versions forward.
• A failed save blocks republishing. If the page's own save in that locale fails, process-sitemap blocks it for the rest of the run. This applies whether the failure comes before or after the save that queued it.
• Without auto-publish of pages (content or off), the run lists these pages under "Pages Left in Staging by Another Locale's Save". They also go into --jsonSummary → autoPublish.warnings, type staging. They don't block the run.
• The new run-scoped registry in state.ts follows the failed-content and held-back-template registries, and is cleared at the start of each push.
• README: one paragraph in the Auto-Publish section.

Out of scope: locales that aren't in the run. The CLI has no pulled state for them, so it can't tell whether the page was Published before the save. agility verify (#235) reports the publish-state difference.

Testing

• refresh-other-locale-versions.test.ts: records the page for each condition above, and doesn't for:
  • already staging on the target
  • still Published after the save
  • staging on the source
  • independent target edit (no API call)
  • blocked before
  • blocked after
• process-sitemap.test.ts: a failed save drops the queued page and stops a later save from queuing it again. An up-to-date skip keeps it.
• push-auto-publish.test.ts (new):
  • executeAutoPublish publishes the page in the locale it went to staging in, and updates that locale's mapping
  • a page already saved in that locale is published once
  • content mode doesn't publish it
• push.test.ts / json-summary.test.ts: the merge and warning helpers, and staging being non-blocking and counted as a warning.
• npx jest (stacked on PROD-2773: warn when content references a CDN container owned by neither the source nor the target #236): 132 suites / 2,534 tests pass. tsc --noEmit is clean. eslint has 0 errors.
• Not verified live yet. That needs a run on a two-locale clone pair after PROD-2776 (server) is deployed: restore the removed components, then check that both locales end up Published.

Jira: PROD-2782. Relates to PROD-2776 and PROD-2628.

🤖 Generated with Claude Code