Install smart_date early: it arrives last in the recipe chain and can deadlock a Drupal CMS install

Problem/Motivation

On a Varbase site template, smart_date is installed only at the very end of the recipe chain. In Educare it is recipe 23 of 24: the template applies varbase_events_base, which applies events, and events both installs smart_date and imports config that uses the smartdate field type (field.storage.node.field_when) plus all of the module's own config (smart_date: "*").

Because it lands that late, an interruption anywhere around it leaves smartdate-typed config in the site with no module behind it, and every subsequent request fatals:

Drupal\Component\Plugin\Exception\PluginNotFoundException:
Unable to determine class for field type 'smartdate'
found in the 'field.storage.node.field_when' configuration

The site cannot then be repaired by installing the module, because the module's own config already exists:

Drupal\Core\Config\PreExistingConfigException:
Configuration objects (smart_date.smart_date_format.compact,
smart_date.smart_date_format.date_only, smart_date.smart_date_format.default,
smart_date.smart_date_format.time_only) provided by smart_date
already exist in active configuration

That is a dead end: the install cannot go forward, and the module cannot be installed after the fact.

This is only reachable through the Drupal CMS browser installer, where each batch step is a separate request. A drush site:install of the same codebase is a single process and completes.

Steps to reproduce

1. Build a Drupal CMS 2.x site on Drupal core 11.4.5 with a Varbase site template (tested with drupal/educare:1.0.x-dev).
2. Install through the browser installer at /core/install.php, choosing the site template.
3. The install stops part way and the site returns HTTP 500 with the first exception above.
4. Running drush pm:enable smart_date then fails with the second exception.

Proposed resolution

Add smart_date to this recipe's install: list, so the module is present early (recipe 13 of 24 in the Educare chain) rather than last.

Note that varbase_events_base already lists smart_date, and events installs it too — the declaration is not missing, it is simply too late. A recipe cannot install a module before its own sub-recipes run, so installing it earlier in the chain is what makes the ordering safe.

Measured on a Drupal CMS build: before the change the browser install stopped at 177 tables with smart_date not enabled; after it, smart_date was enabled by 174 tables and the install ran past that point. The PreExistingConfigException dead end can no longer occur.

Honest scope: this removes the smart_date failure. It does not on its own make the Drupal CMS browser install complete — a separate, still-unidentified failure follows it.

Remaining tasks

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

• Smart Date is installed earlier in the chain. No configuration or content differences on a site that installed successfully before.

Release notes snippet

• Smart Date is installed early, so a site template install can no longer be left with Smart Date fields and no Smart Date module.