Pin block component versions to active, so a stale hash cannot 500 the Canvas pages

Problem/Motivation

The shipped Canvas page regions pin hard-coded component_version hashes for block.* components. That is not portable, and the same pattern makes every Canvas page return HTTP 500 on Horizon Aid on a plain Drupal CMS base (horizonaid #3620437):

OutOfRangeException: The requested version `…` is not available. Available versions: `…`.
  in Drupal\canvas\Entity\VersionedConfigEntityBase->assertVersionExists()

Why a hard-coded hash cannot work for a block component

Canvas auto-creates a component config entity per block plugin — on an installed site it reports provider: system, so Canvas created it, not the recipe. Recipes do not overwrite config that already exists, so the recipe's own canvas.component.block.*.yml never imports and the hash it declared can be left unreferenced. The hash is derived from the component payload, so the value on disk depends on which side created the entity first.

Varbase Starter is the reference template every other Vardot site template is cloned from, so the pattern propagates from here. Horizon Aid and Educare both carry it (educare #3620438).

It is currently masked on Varbase by canvas MR !927 (#3585221), carried in vardot/varbase-patches, which turns the exception into a silent fallback to active_version. That patch is being removed (varbase-patches #622), after which a stale pin is a 500 on Varbase too.

Proposed resolution

Use component_version: active for block.* components. assertVersionExists() accepts a version that equals active_version or is a key in versioned_properties, and active is always such a key, so it cannot dangle; Canvas resolves it to the local component version at import time.

Five block.* pins change:

• canvas.page_region.vartheme_bs5.header.yml — block.system_branding_block, block.system_menu_block.main
• canvas.page_region.vartheme_bs5.footer.yml — block.system_menu_block.secondary, block.system_menu_block.social-media-menu, block.system_menu_block.footer

The sdc.* pins are deliberately left alone. Those components ship with vartheme_bs5, so this recipe controls their payload, their hashes are deterministic, and pinning them is an intentional guarantee.

Remaining tasks

• ✅ File an issue
• ❌ Addition/Change/Update/Fix
• ❌ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support
• ➖ User Guide Documentation support
• ➖ 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

User interface changes

• None expected. This removes a latent failure rather than fixing a visible one.

API changes

• N/A

Data model changes

• Block component references in the header and footer page regions resolve to the local component version at import time rather than a fixed hash.

Release notes snippet

• Pin block component versions to active in the header and footer page regions, so a stale hash cannot make Canvas pages throw OutOfRangeException.

AI-Generated: Yes