"Unable to resolve service" in production only after enabling laminas config cache

Our Laminas MVC application runs cleanly on developer machines, but in production the ServiceManager throws an exception of the form Unable to resolve service \"X\" to a factory for a service whose factory is defined in a module that has been registered in modules.config.php for weeks.

The relevant difference between environments is module_listener_options in application.config.php: production has config_cache_enabled (and the module map cache) turned on, writing the merged configuration into data/cache, while local development does not. We also use the conventional config/autoload/{,*.}{global,local}.php glob, and *.local.php files are excluded from deployment.

What we cannot settle is the intended ownership of the merged-config cache lifecycle. The framework appears to make no decision about when the cached configuration becomes invalid, so every deploy strategy seems to be a convention we must invent ourselves: wipe data/cache on each release, disable the cache entirely, or key the cache file to the release identifier.

Assuming a current laminas-mvc / laminas-modulemanager version pinned in composer.json:

• Is a stale merged-config cache the expected explanation for a production-only Unable to resolve service error, or should we suspect the missing *.local.php overrides first?
• Is there a documented, supported mechanism for invalidating or versioning the config cache at deploy time, or is manual deletion of data/cache the intended practice?
• Does cache behavior differ meaningfully across laminas-modulemanager versions such that we should verify against our pinned release?