cmplz_banner_loader’s wp_enqueue_scripts hook never fires

Question: what could cause an add_action('wp_enqueue_scripts', ...) call made unconditionally in a class constructor to register successfully (object exists, method works when called directly) but never actually fire during a real page-load/dispatch cycle, with no error anywhere in the log? Is there a known interaction with GTM4WP, Directorist, Rank Math, or Astra that’s been reported before?

Environment:

• WordPress 7.1, PHP 8.4.24, locale es_ES
• Complianz GDPR/CCPA Cookie Consent Banner (free) 7.5.5
• Theme: Astra + Astra Child (Astra Addon 4.13.9)
• Other active plugins that touch the frontend: Directorist 8.9.4, Rank Math SEO 1.0.278, Google Tag Manager for WordPress (GTM4WP / duracelltomi-google-tag-manager), HTTP Headers, Limit Login Attempts Reloaded, All-in-One WP Migration, Backuply, Novamira/Novamira Pro (site management), Gravity Forms, Font Awesome
• No caching plugin active (LiteSpeed Cache plugin present but deactivated), no page-cache headers observed on responses

What I configured:

• Fresh install, ran through the setup wizard once
• country_company = ES, regions = eu, eu_consent_regions = yes
• Confirmed via cmplz_get_cookiebanners() that exactly 1 banner exists (ID 1, “Banner A”), disable_cookiebanner = 0
• Confirmed the generated banner CSS file exists on disk at wp-content/uploads/complianz/css/banner-1-optin.css (17KB, non-empty)

The bug:
On a real, uncached frontend request (verified with a headless Chromium/Playwright session — not just curl, to rule out a JS-execution artifact), none of Complianz’s own assets are ever requested: no cmplz-cookiebanner script, no cmplz-postscribe, nothing. Only a plugin CSS file (cookieblocker.css) loads. No banner renders, no script gets rewritten to type="text/plain", and Google Analytics (loaded via Google Tag Manager, unrelated to Complianz) fires a real g/collect hit on first load with no consent gate at all.

What I ruled out before reporting this:

1. Not a code bug: calling COMPLIANZ::$banner_loader->enqueue_assets() directly via WP-CLI works perfectly — it registers the cmplz-cookiebanner script handle in $wp_scripts->registered with no errors or exceptions (tried/caught \Throwable).
2. Not a business-logic gate: COMPLIANZ::$banner_loader->site_needs_cookie_warning() returns true. analytics_configured() returns true.
3. Not a fatal error being swallowed: wp-content/debug.log has no entries from today/this session at all (stale entries from Aug 27 only, from a previous plugin — business-directory-plugin — that isn’t even active anymore).
4. Not WordPress’s plugin auto-pause mechanism: get_option('_wp_paused_plugins') and get_option('_wp_paused_themes') are both empty/false.
5. Not server/page caching: no Cache-Control/Age/X-Cache style headers on any response; the “no-caching-plugin-active” state was confirmed via wp plugin list.
6. Not visitor geolocation: confirmed the test request’s outbound IP geolocates to Sevilla, Spain (i.e., squarely inside the configured eu region), via ipinfo.io.
7. Not a stale/cached page-view: re-tested with cache-busting query strings and fresh Playwright sessions each time, same result every time.

What I couldn’t determine without deeper access:
Since the constructor of cmplz_banner_loader unconditionally calls add_action('wp_enqueue_scripts', [...], PHP_INT_MAX - 50), and COMPLIANZ::$banner_loader is a valid instantiated object of that class (confirmed via WP-CLI), the hook registration itself should be happening on every request — including real frontend ones. I don’t have access to a live debugger (Xdebug) or a way to hook into a real production HTTP request’s execution to see whether something removes this specific action after registration, or whether instantiate_classes()/hooks() is for some reason skipped entirely on real frontend dispatch versus the WP-CLI context. That’s the piece I need your help with.

Happy to provide a full debug.log with WP_DEBUG temporarily enabled, or run any diagnostic snippet you’d like via WP-CLI if that’s faster than a support back-and-forth.