task: #3620438 Pin block component versions to active

#3620438

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

Why

Canvas auto-creates a component config entity per block plugin (provider: system on an installed site). Recipes do not overwrite config that already exists, so the recipe's own canvas.component.block.*.yml never imports and any 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 — a fixed hash for an auto-created block component is non-portable by construction.

assertVersionExists() accepts a version equal to active_version or present as a key in versioned_properties. active is always such a key, so it cannot dangle; Canvas resolves it to the local component version at import.

Educare is not broken today — this is preventative

Educare's captured hashes happen to match what Canvas derives on a Drupal CMS base, so it renders. That is luck, not design.

The same pattern does break Horizon Aid: every Canvas page 500s on a fresh drupal/cms install with OutOfRangeException (horizonaid #3620437, MR !64).

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

What is NOT changed

The sdc.* pins stay as fixed hashes — those components ship with vartheme_bs5_educare, so this recipe controls their payload, the hashes are deterministic, and pinning them is a deliberate guarantee.

Testing

The mechanism and the fix were verified on the Horizon Aid build: rewriting its block pins to active in live config took five routes from 500 to 200, and the footer region that already shipped active was confirmed resolving to concrete per-environment hashes after install.

This branch has not been installed, and Educare renders before the change, so there is no visible before/after to demonstrate here. Testing to ensure no regression stays unticked pending an install on both a Drupal CMS and a Varbase base.

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