fix: #3620437 Pin block component versions to active

#3620437

Changes four block.* pins from a hard-coded hash to active. Nothing else.

The bug

On a plain Drupal CMS base the install completes, then every Canvas page 500s:

OutOfRangeException: The requested version `b168140fdcaebae5` is not available.
Available versions: `7d528e00f56b3abf`.
  in VersionedConfigEntityBase->assertVersionExists()

Reproduced on a fresh drupal/cms + Horizon Aid install: /, /about, /programs, /events, /donate all 500.

Why a hard-coded hash cannot work here

Canvas auto-creates a component config entity per block plugin — on the installed site it reports provider: system, so Canvas created it, not this recipe. Recipes do not overwrite config that already exists, so the recipe's own config/canvas.component.block.system_branding_block.yml (declaring b168140fdcaebae5) never imports. The region is left pointing at a version nothing defines.

The hash is derived from the component payload, so the value on disk depends on who created the entity first. That makes a fixed hash for an auto-created block component non-portable by construction.

Why active is correct

assertVersionExists() accepts a version that equals active_version or is a key in versioned_properties. active is always such a key, so it never dangles. Canvas resolves it to the local component's current version at import.

Verified, not assumed: canvas.page_region.vartheme_bs5_horizonaid.footer.yml already ships active for its block components, and reading that region back out of the database after install shows those active values resolved into concrete per-environment hashes. Same file, same recipe, opposite outcome — the footer renders, the header 500s.

Proven on the failing site by rewriting the header's block pins to active in the live config: all five routes went from 500 to 200.

What is NOT changed

The sdc.* pins stay as fixed hashes. Those components ship with vartheme_bs5_horizonaid, so this recipe controls their payload and the hashes are deterministic. Pinning them to a specific version is a deliberate guarantee, and swapping it for active would throw that away.

Why not patch Canvas

vardot/varbase-patches has been carrying canvas MR !927 (#3585221), which makes assertVersionExists() fall back to active_version instead of throwing. That patch is why this never showed on Varbase — it silently masked every stale pin. Its removal (varbase-patches #622) is what surfaced this.

Fixing the data keeps to what Drupal CMS and Drupal Canvas provide, with minimal additions and minimal patches.

Testing

• Failure reproduced on a fresh drupal/cms + Horizon Aid install.
• Fix proven by applying the same change to the live site's config: 500 → 200 on /, /about, /programs, /events, /donate.
• This branch has not itself been installed end to end, so Testing to ensure no regression is unticked. A full install of this branch on both a Drupal CMS and a Varbase base is the remaining check — particularly on Varbase, where the change should be a no-op but has not been observed.

AI-Generated: Yes

Checkpoints

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