Break stale content locks on edit

Problem/Motivation

Content Lock 3 merged Content Lock Timeout into Content Lock. A lock older than content_lock.settings:timeout is ignored when the next editor opens the form, and released on cron. The old "Break stale locks on edit" option is gone.

varbase_core_install() imports Varbase Core's own content_lock.settings.yml over Content Lock's default. That copy has no timeout key, so the timeout ends up NULL and locks never expire. An editor who closes the tab blocks everyone else until the lock is broken by hand.

A fresh install also enables Content Lock Timeout, which is now deprecated, and ships its Ultimate Cron job.

Seen on a Varbase 9.2.x site built from Varbase Core 9.2.5. The 10.1.x code is the same. Varbase 11 already sets the timeout.

Steps to reproduce

1. Install Varbase 9.2.x or 10.1.x.
2. Run drush config:get content_lock.settings timeout: no value.
3. Open a node edit form as one user, close the tab, then open the same form as another user after 30 minutes: still locked.

Proposed resolution

Both branches, for new installs:

• Add timeout: 1800 to config/optional/content_lock.settings.yml.
• Remove content_lock_timeout from the install: list, and delete its settings and Ultimate Cron job config. Content Lock 3 has its own hook_cron.

Existing sites differ by branch:

• 10.1.x: varbase_core_update_100003 sets the timeout to 1800 only when it is empty, and uninstalls Content Lock Timeout when it is enabled.
• 9.2.x: no update hook. Site owners set Lock timeout at /admin/config/content/content_lock (drush cset content_lock.settings timeout 1800 -y), and can uninstall the stub with drush pmu content_lock_timeout. Content Lock's own post-update does that only on sites upgraded from Content Lock 2.

Reviewer notes (10.1.x hook):

• Uninstalling Content Lock Timeout also removes config that depends on it, such as the content_lock_timeout_cron Ultimate Cron job.
• A site that cleared the timeout on purpose gets expiry turned on again. It cannot be told apart from a site hit by this bug.

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

• New installs: default content_lock.settings:timeout is 1800, and Content Lock Timeout is no longer installed.
• 10.1.x existing sites: the update hook sets an empty timeout to 1800 and uninstalls Content Lock Timeout. 9.2.x existing sites are unchanged.

Release notes snippet

• 10.1.x: stale content locks expire after 30 minutes, and the deprecated Content Lock Timeout module is uninstalled.
• 9.2.x: new installs expire stale content locks after 30 minutes and no longer install Content Lock Timeout. Existing sites: set Lock timeout at /admin/config/content/content_lock (drush cset content_lock.settings timeout 1800 -y), and optionally run drush pmu content_lock_timeout.