The search results page lost its own search box, so the 12-search functional bucket fails

Problem/Motivation

#3621848 stopped the three "block plugin was not found" warnings by pointing the header search panel at the search page display's own exposed block and dropping display.page.display_options.exposed_block: false. Views renders an exposed form either inline OR as a block, never both, so that removed the exposed form from the results page itself.

The result: /search has no visible search field at all — the only one is behind the header toggle — and the view's own "Enter a keyword to search Horizon Aid" message has no field to type into. The 12-search bucket is now the single failing job in the pipeline (all 17 others pass), with:

Then ".view-search-results .views-exposed-form" should have a count of 1
  Expected ".view-search-results .views-exposed-form" count to be 1 (last seen: 0)

and, on the header scenario:

And ".view-search-results input[name='keywords']" should have value "water"
  TimeoutError waiting for locator('.view-search-results input[name=\'keywords\']')

Steps to reproduce

1. Build a plain Drupal CMS site (Drupal core 11.4.6, drupal/canvas 1.11.0, no patches).
2. Install the Horizon Aid site template: drush site:install recipes/horizonaid.
3. Visit /search?keywords=water.
4. The page renders view-search-results but contains no views-exposed-form — there is no search field on the results page.
5. Run the 12-search functional bucket: it fails on the two assertions above.

Proposed resolution

Give the header a plain GET form to /search instead of a Views exposed block, and restore the inline exposed form on the results page:

1. views.view.search action: restore display.page.display_options.exposed_block: false.
2. canvas.page_region.vartheme_bs5_horizonaid.header: replace the block.views_exposed_filter_block.search-page item with an sdc.vartheme_bs5_horizonaid.html-code item carrying a plain HTML form element with action="/search" and method="get", an input[name="keywords"] and a submit button. html-code already ships with the template and is already used in the footer, so no new component and no theme change are needed.
3. Delete config/canvas.component.block.views_exposed_filter_block.search-page.yml, which nothing references any more, and swap the header region's dependency to the html-code component.

The header form needs no Views block, no derivative and no extra display, and it submits keywords exactly as the exposed form does — so both search boxes work and neither depends on config that does not exist yet at import time.

Why the obvious fixes do not work

Both were verified, so reviewers do not repeat them:

• Restoring the dedicated block_1 display and shipping the Canvas Component for it in config/ is what #3621848 correctly removed: a recipe imports its config BEFORE it runs its actions, so the block plugin derivative does not exist yet, Drupal logs the three warnings and saves the Component with no dependencies at all.
• Creating that Component from a config ACTION instead (with entity_create:createIfNotExists, after the action that creates block_1) does NOT work either. Writing the view config does not rebuild the block plugin definitions in the same run, so the derivative is still undiscoverable and the install dies with:
  

  There were validation errors in canvas.component.block.views_exposed_filter_block.search-block_1:
  - source_local_id: The 'views_exposed_filter_block:search-block_1' plugin does not exist.

Verified locally

On a plain Drupal CMS build (Drupal core 11.4.6, drupal/canvas 1.11.0, no patches):

• drush site:install recipes/horizonaid exits 0 with zero warnings and zero errors.
• /search?keywords=health renders the results (Showing 1-10 of 12), the inline exposed form is inside .view-search-results and carries the views-exposed-form--search class, and the header panel form is inside .icon-toggle__panel with its own input[name="keywords"] — two working search boxes.
• The whole 12-search bucket passes: 22 scenarios, 160 steps, all green.

AI assistance disclosure

AI-Generated: Yes — assisted by Claude Code / Claude Opus 5, per the Policy on the use of AI when contributing to Drupal. The install was run and the functional suite executed locally by a human.

Remaining tasks

• ✅ File an issue
• ❌ Addition/Change/Update/Fix
• ❌ Testing to ensure no regression
• ➖ Automated unit testing coverage
• ✅ Automated functional testing coverage
• ➖ UX/UI designer responsibilities
• ➖ Readability
• ➖ Accessibility
• ➖ Performance
• ➖ Security
• ➖ Developer Documentation
• ➖ User Guide Documentation
• ❌ Reviewed by human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ❌ Release notes snippet
• ❌ Release

User interface changes

• The search results page at /search shows its own search box again, above the results.
• The header search panel is a plain form rather than a Views exposed block; it looks and behaves the same.

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• The search results page shows its own search box again, and the header search panel uses a plain form instead of a Views exposed block.