Regression from #3552528: entities-list--single-item replaces entities-list instead of adding to it, breaking themes built on the combined class

Problem/Motivation

#3552528 changed EntityReferenceBrowserWidget::displayCurrentSelection() so that cardinality-1 fields get entities-list--single-item instead of entities-list, rather than as an additional modifier. Gin's own CSS (entity_browser.scss) was already written expecting both classes together — e.g. .entities-list:not(.entities-list--single-item) and .entities-list.entities-list--single-item .item-container only match when entities-list is still present. With it dropped, every rule scoped under .entities-list .item-container — remove/replace/edit button positioning, item border, hover states — stops applying to single-cardinality fields (e.g. a hero image field), even though the original squishing bug is fixed.

Affected version: 2.17

Steps to reproduce

Field with cardinality 1 using the Entity Browser entity_reference widget, Gin as the admin theme, an item selected. Remove/edit buttons render unstyled and inline instead of as positioned circular icons overlaying the thumbnail.

Proposed resolution

Keep `entities-list` unconditional; add `entities-list--single-item` as a modifier only, e.g.:

$classes = ['entities-list'];
if ($this->getCardinality() != 1) {
  $classes[] = 'sortable';
}
else {
  $classes[] = 'entities-list--single-item';
}