Stale Canvas component version pins in the Varbase Starter configuration

Problem/Motivation

Four Canvas component config entities shipped in the Varbase Starter recipe carry an active_version hash that no longer matches the version Drupal Canvas mints for those components from the SDC definitions on disk. Three component instances inside the shipped page regions and patterns pin a component_version that is stale in the same way.

Canvas recomputes every component's settings on rebuild and mints a new version hash when they change, so a recipe that ships a hash from an older build leaves the imported configuration pointing at a version the installed component no longer advertises. This is the same class of defect that was fixed for the Card Logo component in #3607733.

Stale active_version on the component config entities:

• canvas.component.sdc.vartheme_bs5.card-hero — shipped 7b18bf9051fa6725, minted ecdc62ca524b348a
• canvas.component.sdc.vartheme_bs5.icon-toggle — shipped 5a87298f3691cd43, minted c42c2d3c773c4f6c
• canvas.component.sdc.vartheme_bs5.share — shipped 64add9738be2892f, minted 24d3cc5800d6bb4f
• canvas.component.sdc.webshare.share — shipped 64add9738be2892f, minted 24d3cc5800d6bb4f

Stale component_version on the component instances:

• canvas.page_region.vartheme_bs5.header, component sdc.vartheme_bs5.icon-toggle — 5a87298f3691cd43 to c42c2d3c773c4f6c
• canvas.page_region.vartheme_bs5.footer, component block.system_menu_block.secondary — 31ecc6cc06f17d4e to 7206ccf6a90c8941
• canvas.pattern.footer_global, component block.system_menu_block.secondary — 31ecc6cc06f17d4e to 7206ccf6a90c8941

The icon-toggle instance is the header search toggle added in #3615236, so the stale pin sits in the site header.

Steps to reproduce

1. Install the Varbase Starter site template with drush site:install drupal_cms_installer installer_site_template_form.add_ons=varbase_starter.
2. Rebuild the cache so Canvas regenerates the component definitions from the SDC on disk.
3. For every config/canvas.component.*.yml in the recipe, compare the shipped active_version against Component::load($id)->get('active_version') on the installed site, and compare every tree component_version against the versions the loaded component advertises.
4. Seven pins do not match.

Proposed resolution

Re-mint the four component config entities against the components as they ship in Vartheme BS5 5.0.0-rc3, Webshare 2.0.0-beta2 and Drupal Canvas 1.10.1, and re-point the three instances at the minted versions.

Every component keeps the settings it previously shipped. The old active block is archived under its own hash key (7b18bf9051fa6725, 5a87298f3691cd43, 64add9738be2892f) so any tree still pinned to an older version continues to resolve, and the new active block holds the current definitions. No component loses a version.

Verified against an installed site by loading every Component config entity after a rebuild and comparing it to the recipe: 120 component pins and 152 instance pins, zero mismatches after the change.

Remaining tasks

• ✅ File an issue about this project
• ✅ Addition/Change/Update/Fix to this project
• ❌ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support on feature change/addition
• ➖ User Guide Documentation support on feature change/addition
• ➖ 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 varbase_starter-1.0.0-rc1

User interface changes

• N/A

API changes

• N/A

Data model changes

• Four canvas.component.* config entities gain a newly minted active_version. The previously active settings are retained under their original version key, so no shipped component version is dropped.

Release notes snippet

• fix: Re-mint the stale Canvas component version pins in the Varbase Starter configuration