fix: #3622140 Restore the inline exposed form on the search results page

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

What this changes

1. views.view.search action in recipe.yml restores display.page.display_options.exposed_block: false, so the page display renders its exposed form inline again.
2. canvas.page_region.vartheme_bs5_horizonaid.header replaces the block.views_exposed_filter_block.search-page item with an sdc.vartheme_bs5_horizonaid.html-code item carrying a plain GET form to /search with an input[name="keywords"] and a submit button, and swaps the region's dependency accordingly. html-code already ships with the template and is already used in the footer, so there is no new component and no theme change.
3. Deletes config/canvas.component.block.views_exposed_filter_block.search-page.yml, which nothing references any more.

Three files changed, +33 / -49.

Why

#3621848 stopped the three "block plugin was not found" warnings by pointing the header at the page display's own exposed block and dropping exposed_block: false. Views renders an exposed form either inline or as a block, never both, so that removed the search box from the results page: /search had no visible field at all, and the view's own "Enter a keyword to search Horizon Aid" message had nothing to type into. 12-search became the pipeline's only failing job while the other 17 buckets passed.

Both obvious fixes were tried and neither works, stated here so reviewers do not repeat them:

• Shipping the Canvas Component for a dedicated block_1 display in config/ is exactly what #3621848 removed. A recipe imports config BEFORE running actions, so the derivative does not exist yet, Drupal logs the warnings, and the Component is saved with no dependencies.
• Creating that Component from a config action instead (entity_create:createIfNotExists, after the action that creates block_1) fails too: writing the view config does not rebuild the block plugin definitions in the same run, and the install dies with source_local_id: The 'views_exposed_filter_block:search-block_1' plugin does not exist.

A plain form needs no Views block, no derivative and no extra display, and it submits keywords exactly as the exposed form does.

Verification

On plain drupal/cms (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 returns results (Showing 1-10 of 12); the inline exposed form is inside .view-search-results and carries the views-exposed-form--search class; the header panel form is inside .icon-toggle__panel with its own input[name="keywords"].
• The 12-search bucket passes locally: 22 scenarios, 160 steps, all green - the bucket that fails on 1.0.x today.

AI-Generated: Yes

Assisted by Claude Code (Claude Opus 5). Verified by human-run local installs and by running the functional suite locally.

Checkpoints

• Testing to ensure no regression
• Automated unit testing coverage
• Automated functional testing coverage
• Readability
• Accessibility
• Performance
• Security
• Developer Documentation
• User Guide Documentation
• Release notes snippet
• UX/UI designer responsibilities
• Reviewed by a human
• Code review by maintainers
• Full testing and approval
• Credit contributors
• Review with the product owner
• Release

🤖 Generated with Claude Code