### Overview A site installed with `drush site:install` (or any single-process recipe apply) can end up with Component config entities whose `active_version` hash does not match what the current site state generates — and the site stays that way until an unrelated event regenerates components. The same recipes applied through the browser installer produce a different (correct) version history, because the work is split across multiple requests. The cause is how `PersistentPropShapeRepository` refreshes storable prop shapes: - When config that affects prop shapes changes mid-process (e.g. a recipe creates the first image `MediaType`, which flips the Media Library prop-shape alter), the affected cache entries are only queued for re-resolution. They are re-resolved at request/process teardown (`destruct()`), not when component generation next runs. So the regeneration pass at that recipe's own `RecipeAppliedEvent` still computes version hashes from the old shapes and mints nothing. - At teardown, the cold-cache guard in `updateCache()` writes the freshly re-resolved shapes to the cache but deliberately skips `generateComponents()`. On a fresh install the cache is always cold, so this always happens. After that, the state is stable: every later request loads a warm cache whose shapes are correct, nothing is queued, and no code path ever notices that the Component entities' hashes disagree with the cached shapes. The stale hashes persist until something else happens to call component generation — a cache rebuild, a module install, another recipe, saving a View or Menu, or a new prop-shape-affecting config change. Consequences: - Installing the same recipes via `drush site:install` vs. the browser installer produces different component version histories. - A component tree (page region, content template, pattern) shipped by a recipe can reference a version hash that does not exist on the freshly installed site, even though the same export works on a browser-installed site. Since recipe config validation is skipped during the installer, this surfaces as a hard render failure, not a validation error. - The breakage self-heals on the first `drush cr` (or any other regeneration trigger), which makes it very hard to reproduce from bug reports. Found while validating https://git.drupalcode.org/project/drupal_cms/-/work_items/3591419 (site templates breaking on fresh installs due to version hash mismatches). ### Steps to reproduce 1. On a fresh minimal site (no image media type), in a single process, apply a recipe that installs a module/theme providing SDCs with image props, followed by a recipe that creates an image media type (e.g. core's `image_media_type`). 2. Check the versions of an image-prop component: `drush config:get canvas.component.sdc.<theme>.<component> versioned_properties` — it has a single version, whose hash was computed *without* the media type (image field type prop shape). 3. Run `drush cr` and check again — a second version appears and becomes `active_version`, computed *with* the media type (media library reference prop shape). Expected: step 2 already shows the state of step 3, which is also what the browser installer produces (its per-request teardowns re-resolve the shapes between recipes). A kernel test demonstrating all of this exists from the investigation (six scenarios: install orders, single-process vs. simulated multi-request installs, post-install no-op requests) and can be attached to the MR. ### Proposed resolution Make component generation always run against up-to-date prop shapes, instead of shapes that are only refreshed at teardown: - Process the queued prop-shape re-resolutions synchronously before `generateComponents()` computes version hashes (covering the `RecipeAppliedEvent` subscriber, `hook_rebuild()`, and module-install triggers). - Revisit the cold-cache teardown path: it currently writes the corrected shapes to cache while skipping regeneration, which is what strands freshly installed sites in the stale-but-stable state. The guard's goal (avoiding cache self-invalidation churn on cold caches) needs to be met without silently dropping the regeneration. During the same investigation, a second, separate gap was found: array-item prop shapes (e.g. an array-of-images prop) do not carry the `config:media_type_list` cache tag, so tag-based re-resolution misses them even on multi-request installs — only a full cache rebuild catches them. That is tracked in #3591917; this issue is only about the deferral + cold-cache behavior. ### User interface changes None. ### Release notes snippet Component version hashes are now updated correctly during single-process installs (e.g. `drush site:install` with recipes). Previously, components affected by prop-shape-changing config (such as media types) could keep an outdated version hash until the next cache rebuild, causing component trees shipped by recipes to fail to render on freshly installed sites.