Views block exposed filters break when the block is configured through Block field: blockSubmit() assumes $form['settings']

Problem/Motivation

ctools_views Block::blockSubmit() reads the exposed filter elements from $form['settings']['exposed'][...] (Block.php lines 512 and 519 in 4.1.1). That only works when the block is configured through Block Layout or Layout Builder, because core is asymmetric: buildConfigurationForm() and validateConfigurationForm() get the settings subform, while submitConfigurationForm() gets the parent form.

Block field follows the build/validate convention and passes the settings subform as $form, so $form['settings'] does not exist and each exposed filter emits:

Warning: Undefined array key "settings" in Drupal\ctools_views\Plugin\Display\Block->blockSubmit()
Warning: Trying to access array offset on null in Drupal\ctools_views\Plugin\Display\Block->blockSubmit()

Worth fixing regardless of Block field: core #2948549proposes passing the subform to submitConfigurationForm() too, which would break ctools_views the same way in Block Layout itself.

Related: core #2948549 (root
inconsistency) and #3227026 (Layout
Builder counterpart); Block field #3536872
(same gap on the build side) and #3037221
(same code path).

Steps to reproduce

1. View with a block display, "Configure filters" allowed, one exposed filter. Use a taxonomy autocomplete filter to see the data corruption, not just the warnings.
2. Add a block_field field to a content type, widget "Configuration form" set to Full.
3. Edit a node, select the views block, set the exposed filter value, save. Warnings appear.
4. Re-edit the node: the filter value is gone. The same block placed via /admin/structure/block works.

Found on ctools 4.1.1, Drupal 11.4.5, Block field 1.0.0-rc5, PHP 8.3.

Proposed resolution

Resolve the settings subform once at the top of the configure_filters branch and use it for both extractExposedValues() calls:

$settings_form = $form['settings'] ?? $form;

Correct under both conventions, so it fixes Block field today and survives core #2948549. Patch attached, against 4.1.x.

Remaining tasks

User interface changes

API changes

Data model changes