feat: populate reference fields across locales (proof of concept) [CCS-3539]

[ryunsong-contentful]

CCS-3539

What's happening here

Kering asked (via Adrien/Zach in #prd-ecosystem-marketplace) for Locale Field Populator to copy the reference link itself across locales, not just localize the fields inside whatever entry the link already points to. Right now, reference-type fields (Link to Entry, and Array of those) are explicitly excluded from the set of fields the app considers "adoptable" -- everything else about the traversal/write pipeline already works fine for any field type.

This is a proof of concept, not a finished feature -- scoped to prove out feasibility and the UX tradeoffs before committing to full delivery.

Why this needed a design decision, not just a bug fix

A reference field's value can genuinely differ per locale -- that's the whole point of this ask. After copying, a target locale's reference field could end up pointing at a completely different entry than it did before the copy. That breaks the existing diff-preview model (comparing text strings) -- you can't show "before: 4kj2n9, after: 8pq1x2" and expect an editor to know if that's a meaningful change or noise.

Decision: resolve and show the linked entry's title (with a link out), not the raw entry ID, in the source/target preview columns -- falling back to the raw ID if the title lookup fails (deleted entry, permissions, etc.). This mirrors the getEntryTitle pattern ReferenceEntrySection already uses elsewhere in this app, so it stays visually consistent.

Decision: cover all reference field types -- both single-entry Link fields and Array of Link fields, not just single references. The existing traversal code already treats both symmetrically, and limiting scope to one would leave an inconsistent half-feature.

Scope boundary worth calling out: only localized reference fields are affected. A non-localized field has exactly one value across every locale by Contentful's data model -- there's nothing to "populate" for those regardless of field type.

Changes

• SingleEntryReferenceCard.tsx (new) -- fetches and displays a referenced entry's title + link-out, mirroring SingleAssetCard.tsx's fetch/loading/fallback pattern.
• PreviewField.tsx -- reference fields now render SingleEntryReferenceCard (single or list) instead of a static "Reference" / "Reference array" placeholder.
• PreviewFieldRow.tsx -- threads baseUrl through to PreviewField so the new card can build its link-out URL.
• PreviewStep.tsx / ReferenceEntrySection.tsx -- removed the !isEntryField(field) && !isEntryArrayField(field) filters that excluded reference fields from the adoptable-fields set, the "adopt all" bulk action, and the main-entry field-row rendering loop.
• No changes needed to entry.ts's actual CMA write path (updateSingleEntry) -- it was already field-type-agnostic; the bug was entirely upstream in which fields got offered as adoptable in the first place.

Test plan

• adoptedFields.reference.spec.ts (new) -- confirms reference fields (single + array) are included when bulk-adopting a content type's localized fields, can be toggled independently, and that non-localized fields are still correctly excluded
• updateEntries.reference.spec.ts (new) -- confirms a single-Link value and an Array-of-Link value are actually copied to target locales when adopted, and left untouched when not adopted
• Manual: open a Kering-like content type with a localized reference field, confirm the field now appears with an "Adopt this field" checkbox and a resolved entry title in the preview, and confirm the copy actually lands on the target locale after Confirm

Generated with Claude Code