Canvas component versions are not stable across the install lifecycle: content hashes stop resolving after install, and active refs break the import

Problem/Motivation

A component instance in Canvas content records a component_version. The value a component is known by is not the same during the recipe run as it is after the install finishes, so the same literal cannot be correct in both phases.

After a completed install, the shipped page content references version hashes that the component config entities no longer have. On a fresh Drupal CMS + Educare 1.0.x-dev install, 27 of 28 component/version pairs across the 12 Canvas pages do not resolve, for example:

sdc.vartheme_bs5_educare.image   wants 20b07c548b4cf729   has: active   (11 pages)
block.webform_block              wants b5dca6ca0519bf1b   has: active   (Contact Us)

Canvas absorbs this through its fallback source, so pages still render, but every install logs 567 PHP warnings from the fallback branch:

Warning: Trying to access array offset on null   (378)
Warning: Undefined array key ""                  (189)
  in Drupal\canvas\Entity\Component->sourcePluginCollection()
  web/modules/contrib/canvas/src/Entity/Component.php

plus 20 severity-3 RuntimeException ... during rendering of component entries across Home, News, Events, About, Student Life, Anthropology and Explore programs.

The opposite direction is a hard failure. Converting the content to component_version: active - matching what #3620438 did for the config - aborts the recipe at 119 of 122 operations:

Drupal\Core\DefaultContent\InvalidEntityException:
recipes/educare/content/canvas_page/683c9181-64f9-4a13-8ad9-59cd5d4eb89a.yml:
components.23.component_version='active' is not a version that exists on component
config entity 'block.views_block.events-latest'. Available versions: '6ed1e9aa7565cbad'.

So at import time those components carry hashes and active is invalid; after the install they carry active and the hashes are invalid.

This is also reachable as a user-visible failure. #3620438 pinned the page-region and content-template block references to active. On a site whose block components hold hash versions, opening the Canvas editor reports:

'active' is not a version that exists on component config entity 'block.system_branding_block'. Available versions: '7d528e00f56b3abf'.
'active' is not a version that exists on component config entity 'block.system_menu_block.main'. Available versions: '322535c0078cf59c'.

Steps to reproduce

1. Build Drupal CMS and require the recipe:
   

   ddev config --project-type=drupal11 --docroot=web
   ddev composer create-project drupal/cms
   ddev composer config minimum-stability dev
   rm composer.lock
   ddev composer require drupal/educare:1.0.x-dev

2. Install through the browser installer, picking the Educare site template.
3. Compare what the content references with what the components have:
   

   drush sql:query "SELECT COUNT(*) FROM watchdog WHERE type='php'"

   567 warnings, all from sourcePluginCollection().

4. To see the import-time half, rewrite every component_version in content/canvas_page/*.yml to active, drop the database and install again. The recipe aborts with the InvalidEntityException above.

Proposed resolution

Not settled, which is why this is filed for discussion rather than with a merge request. Editing the literals cannot fix it: whichever value is written is wrong in one of the two phases. Options that look viable:

• Resolve active at content-import time, so the recipe can ship active throughout (needs a Canvas change).
• Give components a stable version identifier that survives the install, rather than one that changes as config is imported.
• Have the recipe rewrite the content references after import, to whatever version the components ended up with.

The user-visible impact today is log noise plus the editor error above; pages render and Canvas editing and publishing work.

Remaining tasks

• ✅ File an issue
• ❌ Agree the approach
• ❌ 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

• N/A

API changes

• N/A

Data model changes

• Possibly: how component versions are recorded in shipped default content.

Release notes snippet

• N/A until the approach is agreed.