Exposed checkbox/radio filter loses its "checked" state after filtering (with Better Exposed Filters)

Problem/Motivation

When this module's filter (entityreference_filter_view_result) is exposed and its widget is rendered as checkboxes via Better Exposed Filters, the filtering itself works correctly — but after submitting the form, the previously-selected option no longer shows as checked, and any "active filter" tags/pills that read the checkbox state don't appear either.

In EntityReferenceFilterViewResult::valueForm(), after computing the correct selected value, the code does this:

$user_input[$identifier] = $default_value;
$form_state->setUserInput($user_input);

This directly overwrites the form's raw user input while the form is still being built. Core's own filter base classes (e.g. ManyToOne, used by the standard taxonomy filter) never do this — they only set #default_value on the element and let Drupal's normal Form API pipeline handle the rest.

Because this happens partway through the form build, it collides with how Better Exposed Filters (and Drupal core's Checkboxes element) later read/rebuild that same raw user input, so by the time the checkboxes actually render, the selection information has been lost — even though the value was computed correctly a moment earlier.

Steps to reproduce

1. Create a view with a filter using this module's plugin.
2. Expose the filter and set its widget to checkboxes (e.g. via Better Exposed Filters).
3. Load the page, select an option, submit.
4. Results are filtered correctly, but the checkbox for the selected option is not shown as checked.

Proposed resolution

Remove that block entirely. The element's #default_value (already set right above it) is sufficient — this matches the pattern used by core's own filter classes and fixes the checked-state issue without affecting how the actual query filtering works (which goes through a separate code path, acceptExposedInput()).

Remaining tasks

User interface changes

API changes

Data model changes