Move Search after Varbase Content Base in recipe.yml

Problem/Motivation

The recipe.yml for the Horizon Aid site template lists the Search recipe (drupal_cms_search) before the five Varbase base recipes (Varbase Admin Base, Varbase Security Base, Varbase Media Base, Varbase Editor Base, Varbase Content Base) that build out the site's core content structure.

The Search recipe's own recipe.yml applies two wildcard config actions when it is applied: it sets a Search API Exclude third-party setting on every existing node.type.*, and it clones every existing core.entity_view_display.node.*.default view display into a matching node.%.search_index display. Both actions only act on content types that already exist at the moment Search is applied, so running Search before the Varbase base recipes means it wires up less of the site's eventual content structure than it could.

Horizon Aid's own CI documents a related, more serious failure in this same wildcard clone step: without the curated Drupal core patch for #2741429, a fresh install currently dies inside drupal_cms_search's display cloning with getConfigDependencyName() on null (see the comment above the vardot/drupal-core-patches require line in .gitlab-ci.yml). Applying Search later, after the Varbase base recipes have finished shaping the config graph, reduces how early and how exposed this wildcard clone runs, on top of the existing patch-based fix.

Steps to reproduce

1. On the 1.0.x branch, open recipe.yml and note that drupal_cms_search is listed immediately after drupal_cms_accessibility_tools and before easy_email_express, i.e. before varbase_admin_base, varbase_security_base, varbase_media_base, varbase_editor_base and varbase_content_base.
2. Apply the Horizon Aid recipe (drush recipe:apply recipes/horizonaid, or install through the site template picker) and note that Search's wildcard config actions (node.type.* → enable Search API Exclude, core.entity_view_display.node.*.default → clone into node.%.search_index) run before the Varbase base recipes, in particular Varbase Content Base, have finished.
3. See the comment above the vardot/drupal-core-patches require line in .gitlab-ci.yml, which documents that without that patch, install "dies in drupal_cms_search's display cloning with getConfigDependencyName() on null" — referencing drupal.org core issue #2741429.

Proposed resolution

• Move drupal_cms_search in recipe.yml to apply after varbase_content_base (and the rest of the Varbase base recipes), instead of before all of them.
• Re-export the two Canvas block components placed in the header region (block.system_branding_block, block.system_menu_block.main) and the header page region (canvas.page_region.vartheme_bs5_horizonaid.header) so their active_version / component_version hashes stay in sync with the component config produced after the reorder.

Remaining tasks

• ✅ File an issue about this project
• ✅ Addition/Change/Update/Fix to this project
• ✅ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support on feature change/addition
• ➖ User Guide Documentation support on feature change/addition
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ✅ Update Release Notes
• ✅ Release, horizonaid-1.0.0-alpha2

User interface changes

• N/A

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• Applied the Search recipe after the Varbase base recipes so its automatic search wiring covers more of the site's content structure.