Error handling for action buttons that have limit validation errors in place

Problem/Motivation

Opening the AI Auto-reference "Suggest from existing terms (Form)" modal on a node with an options_select entity reference field crashes with two bugs:

• TypeError in WidgetBase::massageFormValues(): receives a string (the raw entity ID, e.g. "453") instead of an array. options_select has multiple_values: TRUE, so its widget element's #parents is set to ['field_name'] directly — no ['widget'] subkey — meaning the raw POST value is a scalar. Because FieldWidgetFormActionBase::actionButton() sets #limit_validation_errors = [], OptionsWidgetBase::validateElement() never runs to convert the scalar to the expected array structure. When openModalCallback() calls buildEntity(), extractFormValues() passes the raw scalar to massageFormValues(array $values, ...)
• Null entity type manager: $entity_type_manager and $entity_display_repository constructor parameters are not declared protected, so PHP constructor promotion never fires. They are passed as extra args to parent::__construct() (which accepts only 7 parameters and silently ignores extras), leaving $this->entityTypeManager and $this->entityDisplayRepository unset. buildModalForm() then crashes with "Call to a member function getStorage() on null".

Steps to reproduce

• Configure an entity reference field on a node type to use the options_select widget
• Enable the "Suggest from existing terms (Form)" field widget action on that field
• Edit an existing node where the field already has a value selected
• Click the AI suggestion action button

Proposed resolution

In AiAutoReferenceFormSuggestion:

• Override buildEntity() to catch \Throwable and fall back to $form_object->getEntity() when unvalidated form state causes massageFormValues() to receive a scalar. The fallback (saved entity) is sufficient for buildModalForm(), which only needs entity type/bundle/field-definition context.
• Declare $entityTypeManager and $entityDisplayRepository as explicit class properties and assign them in the constructor body. Remove the extra args from the parent::__construct() call.

Remaining tasks

• Review whether the buildEntity() fallback should also cover other widget types with multiple_values: TRUE that exhibit the same scalar-value problem
• Consider whether FieldWidgetFormActionBase itself should guard buildEntity() calls (since any plugin subclass inherits this fragility)

User interface changes

N/A

API changes

N/A

Data model changes

N/A