feat: #3617244 Add the header search toggle and make the results page readable

Issue: #3617244 Add the search index view modes and displays for the content types and taxonomy terms

The index and its view modes landed earlier on this issue. Nothing reached them: the header carried only the logo and the main menu, so a visitor had no way to search, and the results page was not usable as shipped.

What this adds

A search control in the header. The Icon Toggle component is placed in the header region with the search view's exposed form in its slot, so the header stays a logo and a menu until a visitor asks for search. A new block_1 display on views.view.search serves that panel; the page display's exposed_block is turned off so the results page renders its own form inline instead of borrowing the header's.

A readable result row. The index holds both nodes and Canvas pages, so the view carries one title field per entity type and only ever fills one of them — every row rendered an empty heading beside the real one and linked twice. Both titles are now carried as excluded sources and a single linked heading is built from whichever is set, sized at the design system's h4 step, followed by the excerpt. Rows carry mb-5.

The result summary uses the same markup every other listing on this site uses, so the results page reads like the rest of it.

A prompt instead of an empty panel. /search with no query rendered an empty bordered box; it now asks for a keyword.

Automated functional testing coverage

A 12-search suite (22 scenarios, 3 feature files) in the Varbase functional testing suite covers the toggle being present and collapsed at rest, opening to reveal the field, submitting from the header and landing on the results page with the query carried, exactly one h1, the inline filter bar, one heading and one link per row with no empty headings, uniform row spacing, the pager, the empty state and the no-query prompt. Wired into the CI matrix as its own bucket, and listed in tests/README.md and tests/TAGS.md.

Both keywords inputs on the site — the header panel's and the results page's — are addressed by scoped selectors, because a bare input[name="keywords"] matches the hidden header one first.

Verified

Clean install from a dropped database (drush site:install recipes/horizonaid), exit 0, zero errors and zero exceptions logged, 78 items indexed. In a real browser at 1440px and 390px: 1 h1 on every results state, 0 rows with a second or empty heading, exactly 1 link per row, uniform 48px row spacing, header search lands on /search?keywords=… with the value carried back into the page's own field, pager moves 1-10 → 11-20 of 33 and keeps the query, empty-state notice at 14.61:1 contrast, 0 broken blocks, 0 console errors.

The suite runs green against that install: 22 of 22 scenarios, 156 of 156 steps.

One import-time warning remains and is inherent to the ordering rather than to this change: the header region references the block before the config action that creates the block_1 display has run, so The "views_exposed_filter_block:search-block_1" block plugin was not found is logged during the recipe batch. Recipe config files are installed before config actions, and the action cannot run first. The block resolves once the recipe finishes — the header renders it, and no error is logged at runtime.

Depends on the theme change in vartheme_bs5_horizonaid!21 (merged) (#3617499), which gives the results page its heading and keeps the filter bar on one line.

AI-Generated: Yes

Checkpoints:

• 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