[6.x] Restore “Copy value from site…” on translatable fields

[riasvdv]

Description

Restores the cross-site copy action for translatable fields in the new field renderer.

 Field actions
+└── Copy value from site…
+    ├── Select another supported site
+    └── Replace the rendered field and its value

The action is only offered for persisted, editable, translatable fields on elements that support cross-site copying. The copy response now includes the updated form node and values so the field can refresh without reloading the element editor.

[linear-code]

CMS-2349

[github-actions]

📚 Storybook previews

@craftcms/ui — open Storybook

No changed components detected in this Storybook.

resources/js — open Storybook

No changed components detected in this Storybook.

[github-actions]

This PR had conflicts with 6.x. Claude attempted an automatic resolution and pushed a merge commit. Please review the merge commit carefully before approving/merging.

Claude's response

Merge resolved, committed as 192bb87, and pushed.

Summary

The merge of 6.x into this branch had a single conflicted file: resources/js/modules/forms/FieldNode.vue.

The conflict: both sides edited the opening attributes of the <craft-field> element. Our branch (f499447, "Restore cross-site field value copying") refactored the component to read from a new local resolvedNode ref instead of props.node directly — so the field can be re-rendered with a server-returned node after copying a value from another site — and added ref="field" so the cross-site copy event listener can scope events to this field. The 6.x side (8603ddd, "Give all fields an ID") added a :id="fieldId(control.path)" binding plus the corresponding fieldId import.

Resolution: these are independent, non-exclusive changes, so I kept both — our ref="field" and the full resolvedNode.props.* rewrite of every attribute, with 6.x's :id="fieldId(control.path)" inserted alongside. The fieldId import had already auto-merged cleanly. I verified the result by diffing the resolved file against our side: it differs by exactly the two additions from 6.x and nothing else. Nothing ambiguous here — no # CONFLICT-REVIEW: comments were needed.

I also spot-checked the auto-merged CHANGELOG.md, since that file's repeated bullet structure is a known source of silent mis-merges. Our branch never touched it, so the merged version correctly matches 6.x verbatim, with no duplicated section headers.

One caveat for the reviewer: node_modules isn't installed in this environment, so I could not run pnpm typecheck, lint:js, or Prettier to confirm the result passes CI. The change is a two-line template/import addition matching 6.x's own formatting, but CI is the real check.