Caching inconsistency issue with schema cache that has extensions

Digging further through this reveals a whole now world of issues.
While SdlSchemaPluginBase somewhat is the "source" of the issue it is very hard to solve it just there because contrib modules e.g. graphql_core_schema overwrite parts of "it" and do their own caching thing - which runs into the same stale issues as SdlSchemaPluginBase itself has.
I'm not sure if the 5.x branch has the same issues, I can see that it seems to use a different approach but I'm not certain it mitigates the caching problem.
Ultimately it seems to boil down that contrib modules extending SdlSchemaPluginBase have to ensure cache consistency either by not caching intermediaries at all or some other sort of consistency check.
This might become really tricky because we do not have that much control over what contrib does in regards to caching.

Right now the most control we'll ever have over cache consistency seems to be the fact that by default we control the cache.graphql.ast service. So I'm wondering if we could exert control over intermediary cache items by modifying that service instance so that it only allows our fully built schema into a persistent cache and everything else is just stored in a static cache during the process.
However, a look into graphql_compose showed that there is already an example of an extra caching bin being used - and a contrib module with some sanity checks on it's own to probably fix this / similar caching issues:

    // Sanity check. Has any critical component been dropped from cache?
    $has_full_ast = $this->astCache->get($this->getCacheId('full'));
    $has_schema_ast = $this->astCache->get($this->getCacheId('schema'));
    $has_schema = $this->definitionsCache->get('graphql_schema');
    $has_extensions = $this->definitionsCache->get('graphql_schema_extension');

    // If so, register our plugins.
    if ($this->inDevelopment || !$has_full_ast || !$has_schema_ast || !$has_schema || !$has_extensions) {
      // Add GraphQL Compose EntityType plugins to the registry.
      $this->gqlEntityTypeManager->getPluginInstances();
      // Add GraphQL Compose SchemaType plugins to the registry.
      $this->gqlSchemaTypeManager->getPluginInstances();
    }

I've tried to integrate the above outlined gated ast caching wrapper together with a bunch of documentation regarding the ast caching.
At the moment I've no idea about a less intrusive way that would make it possible to control the ast caching - ideas more than welcome :)

⚠️Current code has been generated using LLM support. I'm not done reviewing it - consider it a draft!⚠️

Did my outstanding review - I'm still not able to come up with a better architectural approach that allows a transparent fix of the issue.
The generated code seems clean in terms of what & how.
The in code documentation is quite verbose / extensive even duplicated in parts - but the potential issue almost demands a detailed explanation to ensure nobody "optimizes" this back into a failing state.
The generated tests seem to properly capture the spirit of why this was implemented and test for exactly the things one wants to capture - including the module upgrade behavior which should be as transparent as possible to contrib.
The only concern left is that a contrib module uses a different cache bin / not the wrapped $this->astCache instance - but there's not really anything we can do about this.
I've addressed the open phpstan / phpcs warnings raised by the pipeline.
This code is now running in our test-bed - setting to needs review to hopefully get some more eyes on it :)