fix: Set the session cookie lifetime to 0 so Persistent Login works on a fresh install

Problem/Motivation

Every fresh Varbase 11 install reports a red error on /admin/reports/status:

Session cookie lifetime — Persistent Login requires the session cookie lifetime to be 0. It is currently 2000000.

Varbase ships the Persistent Login module, and the installed site's services.yml carries no override for session.storage.options: cookie_lifetime, so the value stays at Drupal core's default.services.yml default of 2000000. The consequence is twofold: Persistent Login does not behave as intended, and every brand-new Varbase 11 site greets the site owner with a red error on the status report out of the box.

This is a regression, not a missing feature. An auto-configuration that sets cookie_lifetime: 0 through the post Drupal Scaffold procedure was already added in #3443948 and released in Varbase 9.1.3 and 10.0.0-rc3. A fresh Varbase 11 install still reports 2000000, so that existing mechanism is no longer taking effect on the 11.0.x line. The first question is therefore why it stopped applying, rather than what to add.

Reproduced identically on both install paths (Drush and the browser installer), so it is not path-specific.

Found during pre-release install verification for Varbase 11.0.0-rc1. It does not block that release. The reproduction environment is still available.

Environment: Varbase 11.0.x-dev HEAD, Drupal core 11.4.5, PHP 8.4.20, MariaDB 11.8.6, DDEV.

Steps to reproduce

1. Install Varbase 11 (11.0.x-dev) on a clean database, by any method.
2. Log in as the administrator and go to /admin/reports/status.
3. Observe the red "Session cookie lifetime" error.

Proposed resolution

A follow-up verification pass found a constraint that narrows the options:

• varbase_project sets no drupal-scaffold file overrides, so an installed site gets Drupal core's default.services.yml with session.storage.options.cookie_lifetime: 2000000. There is no services.yml on the installed site, and no Varbase recipe ships one.
• A recipe cannot fix this: sites/default/services.yml is a site-level file, not configuration, so it is outside what config and config_actions in a recipe can write. Moving which recipe enables Persistent Login (for example from varbase_users_base to varbase_starter) changes where the module is enabled, but on its own will not clear the red status row.

That leaves two viable routes, for the maintainer to choose between:

1. Have varbase_project scaffold a sites/default/services.yml, or a scaffold override, that sets cookie_lifetime: 0.
2. Do not enable Persistent Login by default, so the requirement does not apply.

The scaffold path is also the likely home of the mechanism from #3443948 — worth confirming what it did and why it stopped applying on 11.0.x, since that is what makes a recipe-based restoration insufficient on its own.

• Whichever route is taken, verify the status report afterwards on a clean install.

Remaining tasks

• ✅ File an issue
• ❌ Addition/Change/Update/Fix
• ❌ Testing to ensure no regression
• ➖ Automated unit testing coverage
• ➖ Automated functional testing coverage
• ➖ UX/UI designer responsibilities
• ➖ Readability
• ➖ Accessibility
• ➖ Performance
• ➖ Security
• ➖ Developer Documentation
• ➖ User Guide Documentation
• ❌ Reviewed by human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ➖ Review with the product owner
• ➖ Release notes snippet
• ❌ Release

User interface changes

• N/A

API changes

• N/A

Data model changes

• N/A

Release notes snippet

• N/A

AI-Generated: Yes