PathAliasConstraintValidator compares every site's alias against site #0's alias, blocking pending revisions on multisite content

Problem/Motivation

Core's \Drupal\path\Plugin\Validation\Constraint\PathAliasConstraintValidator blocks changing the URL alias on a pending (non-default) revision by comparing the alias being saved against the current default revision's alias:

if ($value->alias != $original->getTranslation($entity_langcode)->path->alias) {
$original->…->path->alias resolves through FieldItemList::__get(), which always reads delta 0 of the field — correct when path is single-valued, which is core's assumption.

sites_pathauto raises the computed path field to unlimited cardinality, with one item per site (SitesPathautoFieldItemList), each item carrying its own site_id and alias. The validator runs once per item (Symfony validates each field item separately), but always compares that item against delta 0 — i.e. whichever site happens to sit first in the site list — regardless of which site is actually being validated.

The practical effect: saving a pending revision of any multisite node (e.g. moving content to a "Draft" moderation state without touching any alias) raises a false "You can only change the URL alias for the published version of this content." violation for every site except the one at delta 0. On an install with N sites, that's N-1 spurious violations blocking the save.

Steps to reproduce

1. Enable sites_path_alias + sites_pathauto with content moderation.
2. Add a node to two or more sites, each with its own alias.
3. Save a pending revision (e.g. transition to Draft) without changing any alias.
4. $node->validate() returns a PathAlias violation for every site whose alias differs from the site at delta 0 of the path field — even though nothing changed.

Proposed resolution

Override PathAliasConstraintValidator (via the class-name-as-service-ID technique, so no core patch is required) with a version that matches the original item by site_id instead of always comparing against delta 0, falling back to core's exact delta-0 behavior when the item carries no site_id (non-multisite entities, so behavior for plain path fields is unchanged).

A working patch plus a kernel test reproducing the false positives (and confirming a real alias change is still correctly caught) is attached / available on request.