Report entity reference validation errors in field item order

While working on #2438017: Entity reference does not validate auto-created entities and #2800875: Autocreate for Entity Reference selection handlers that extend ViewsSelection, I noticed that entity reference validation errors do not always follow the order of the field items.

Problem/Motivation

ValidReferenceConstraintValidator reports rejected new targets before rejected existing targets, regardless of their positions in the reference field.

With mixed existing and autocreated targets, the resulting messages can therefore appear in a confusing order.

The reproduction below uses User references: the User selection handler can reject autocreated accounts based on their roles. This demonstrates the problem using existing Core functionality.

The problem would become more widely visible with #2438017: Entity reference does not validate auto-created entities, which adds validation of autocreated entities' own constraints, and #2800875: Autocreate for Entity Reference selection handlers that extend ViewsSelection, which adds Views-based autocreate selection.

Steps to reproduce

1. Add a multivalue entity reference field targeting Users.
2. Use the standard autocomplete widget with separate inputs (not the Tags-style one), and enable autocreate.
3. Restrict selectable users to a particular role.
4. Enter the following references, using existing accounts without that role and new account names:
   • User Two (existing)
   • User Three (new)
   • User Four (existing)
   • User Five (new)
   • User Six (existing)
5. Submit the form.

All five targets are rejected, but their validation messages appear in this order: User Three, User Five, User Two, User Four, User Six.

This also interacts with #2818437: FormState::setErrorByName does not set multiple errors on the same element. A single Tags-style autocomplete widget retains only the first, so violation order can determine which invalid entry is reported and which aren't.

Proposed resolution

Keep the existing batch checks for new and existing targets. Once both checks are complete, report referenceability violations by iterating the original field items.

Preserve message templates, invalid values, property paths, and the existing exception for previously saved references that are no longer accessible.

User interface changes

Validation errors for mixed existing and new entity references follow field item order.

Their still suboptimal wording remains unchanged for now and is covered in #3632280: Make entity reference validation messages consistent and accurate.

Before

After

API changes

None.

Data model changes

None.

Remaining tasks

Review and run Core CI.