DOT_PUBSUB_PROVIDER_OVERRIDE cannot be set via environment variable, silently falling back to the JDBC provider

Problem

DOT_PUBSUB_PROVIDER_OVERRIDE cannot be set through an environment variable, so a containerised deployment that intends to use Redis pub/sub can silently keep running on the default JDBC provider.

DotPubSubProviderLocator reads the override with System.getProperty first, and the property name is already DOT_-prefixed. dotCMS's env-to-property convention prefixes an env var with DOT_ to derive the property name, so:

• DOT_PUBSUB_PROVIDER_OVERRIDE as an env var maps to a property that is not the one read.
• DOT_DOT_PUBSUB_PROVIDER_OVERRIDE is the mechanically "correct" double-prefixed form, but does not work either.

Reproduce

Start a container with:

environment:
  DOT_DOT_PUBSUB_PROVIDER_OVERRIDE: 'com.dotcms.dotpubsub.RedisPubSubImpl'

The log still shows JDBCPubSubImpl being loaded. The only form that works is a JVM system property:

environment:
  CMS_JAVA_OPTS: '-DDOT_PUBSUB_PROVIDER_OVERRIDE=com.dotcms.dotpubsub.RedisPubSubImpl'

Impact

Silent misconfiguration rather than a failure: an operator who sets the env var believes the cluster is on Redis pub/sub while it is on the database. There is no warning, and the only way to tell is reading the provider name from the startup log. Anyone who configured this via env var in production may not be running the transport they think they are.

Acceptance criteria

1. DOT_PUBSUB_PROVIDER_OVERRIDE is settable by environment variable, resolving through the standard Config mechanism rather than System.getProperty directly.
2. The property name follows the same convention as every other dotCMS setting, so the DOT_ prefix is not baked into the name.
3. The resolved provider class is logged at INFO on startup, so the effective configuration is visible without a debugger.
4. If the override names a class that cannot be loaded, that fails loudly instead of falling back silently.
5. Whatever spelling ends up working is documented, and any existing docs or compose examples using the env-var form are corrected.

Notes

Found while trying to force a failing pub/sub provider during local verification of #36803 / #36864. Not caused by those changes — the direct System.getProperty read predates them. Consider whether other settings read the same way.

Start with DotPubSubProviderLocator and trace how the standard Config mechanism maps environment variables to property names, then inspect the startup path and existing documentation or compose examples. Done means the intended env-var spelling resolves the provider, the effective class is logged at INFO, invalid classes fail loudly, and the working spelling is documented.