Propagate tenant config overrides into client-Java listener dispatch

[TIVMOF]

Problem

The {appUrl} notify token (#6642) resolves through Configuration, whose per-tenant override
lookup depends on a thread-scoped map. That map is only populated by
TenantConfigurationInitFilter, an HTTP-request-only filter. A generated notification fires from a
background MessageHandler, dispatched by ListenerClassConsumer — which re-establishes the
tenant's identity (tenantContext.execute(tenantId, ...)) but never loads that tenant's config
overrides. So a tenant that configured their own DIRIGIBLE_APP_BASE_URL still got the global
default in their notification emails — silently. The same gap affects any tenant-overridable config
value read from inside any client-Java listener, not just notifications.

Fix

ListenerClassConsumer.dispatch() now mirrors TenantConfigurationInitFilter's exact pattern, just
triggered from message dispatch instead of an HTTP request:

tenantContext.execute(tenantId, () -> {
    Configuration.setThreadConfiguration(tenantConfigurationService.resolveInjectableForCurrentTenant());
    try {
        dispatcher.onMessage(text);
    } finally {
        Configuration.removeThreadConfiguration();
    }
    return null;
});