fix: #3620437 Pin the header SDC component versions to active

#3620437

Follow-up to fb31b05 (MR !64 (merged)), which pinned only the three block.* entries. This sets the remaining three sdc.* entries in config/canvas.page_region.vartheme_bs5_horizonaid.header.yml to active, so all six components in the header region are pinned the same way. Three lines changed, nothing else.

#	component_id	Was	Now
1	sdc.vartheme_bs5_horizonaid.section	4171719f53c41b9d	active
2	block.system_branding_block	active (fb31b05a)	active
3	sdc.vartheme_bs5_horizonaid.group	aef7f7b22127c944	active
4	block.system_menu_block.main	active (fb31b05a)	active
5	sdc.vartheme_bs5_horizonaid.icon-toggle	c42c2d3c773c4f6c	active
6	block.views_exposed_filter_block.search-block_1	active (fb31b05a)	active

This deliberately overrides a decision recorded on the issue

Issue #3620437 excluded the sdc.* pins on purpose, on this stated rationale:

Those components ship with vartheme_bs5_horizonaid, so this recipe controls their payload and their hashes are deterministic. Pinning them to a specific version is intentional, and replacing that with active would discard a real guarantee.

That reasoning is sound in principle, but the determinism assumption does not survive contact with a real install. On a fresh install of recipe commit 088941e on drupal/varbase_project:11.0.x-dev (Drupal 11.4.6, Canvas 1.10.1, vartheme_bs5 5.0.0-rc5), the two sdc.* pins that could be measured were both stale:

sdc pin	Shipped in the header config	Active on the installed site
sdc.vartheme_bs5_horizonaid.section	4171719f53c41b9d	9b679273be9319ad
sdc.vartheme_bs5_horizonaid.icon-toggle	c42c2d3c773c4f6c	9b1120a77a9891d1

This was on a Varbase base, not even a Drupal CMS one.

Canvas auto-creates a canvas.component.* config entity for a theme SDC just as it does for a block plugin, so the same "whoever creates the entity first wins" mechanism this issue identified for block.* applies to sdc.* as well. The difference is only in the failure mode:

• a stale block.* pin throws fatally (the OutOfRangeException that 500s every Canvas page, which is what this issue was filed for);
• a stale sdc.* pin falls back to the active version silently (Canvas logged 20 version not found, falling back to active version warnings).

So the guarantee read as intact only because nothing threw. In practice the pinned hash was already being ignored at runtime, while still being the value the recipe shipped.

Consistency with the recipe's own convention

config/canvas.page_region.vartheme_bs5_horizonaid.footer.yml already uses active for all 17 of its components. This makes the header match the footer rather than introducing a new convention.

Nothing in recipe.yml acts on canvas.page_region.*, so the only consumer of these values is the config import itself.

Verification

With all six set to active, every page returned 200 both anonymous and authenticated:

/, /countries, /programs, /events, /resources, /about, /donate, /user/login, /admin/content

with zero watchdog errors and zero OutOfRangeException.

The 📐 YAML lint job's script was also run locally against this branch: 493 YAML files checked, 0 invalid.

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