Add TypeNameMatcher to RecipeClassLoader allowlist; align with moderne-recipe-loading-commons

[pdelagrave]

Problem

RecipeClassLoader.PARENT_DELEGATED_PREFIXES and the parallel loadFromParent list in moderne-recipe-loading-commons (which this class was forked from in #6437) have drifted. The most acute miss: org.openrewrite.java.TypeNameMatcher, recently added as a parameter type to TypesInUse.hasTypeMatching(TypeNameMatcher, boolean).

Because TypesInUse is in the allowlist (parent-loaded) but TypeNameMatcher was not, the recipe artifact's classloader loaded its own copy of TypeNameMatcher, while TypesInUse (parent-loaded) was compiled against the parent's copy. When a recipe-loaded UsesType.visit() invokes TypesInUse.hasTypeMatching(TypeNameMatcher, …), the JVM enforces a loader constraint and throws LinkageError because the two classloaders disagree on TypeNameMatcher's identity.

In production this fires once per (recipe instance × source file) pair, with a multi-KB stack trace recorded in SourcesFileErrors each time. On Spring-heavy customer portfolios it produces hundreds of MB to tens of GB per repo and filled worker disks today (Moderne ops/issues#867).

Solution

Add org.openrewrite.java.TypeNameMatcher to PARENT_DELEGATED_PREFIXES so both the recipe classloader and the parent classloader resolve to the same TypeNameMatcher Class object.

While here, bring in the other entries from moderne-recipe-loading-commons's allowlist that reference OSS classes and have drifted out of this one over time. They're all engine API surface that recipe code touches and would produce the same kind of failure if the parent and recipe ever held different versions:

• org.openrewrite.Singleton (added on the commons side in moderneinc/moderne-recipe-loading-commons#69, never ported here)
• org.openrewrite.gradle.attributes.Category / ProjectAttribute
• org.openrewrite.java.Java17Parser
• org.openrewrite.maven.attributes.Attributed
• org.openrewrite.polyglot
• org.openrewrite.protobuf.ProtoVisitor
• org.openrewrite.rpc.{Reference, RpcCodec, RpcObjectData, RpcReceiveQueue, RpcRecipe, RpcSendQueue}

Entries from the commons allowlist that reference proprietary Moderne artifacts are intentionally not included here, since they don't exist in OSS rewrite-core's classpath:

• org.openrewrite.cobol.CobolPreprocessor[Iso]Visitor lives in moderneinc/rewrite-cobol (proprietary)
• org.openrewrite.nodejs.NpmExecutor lives in moderneinc/rewrite-nodejs (proprietary)
• io.moderne.devcenter.* (proprietary)

Two further entries that exist in the commons allowlist but appear to refer to nonexistent classes (org.openrewrite.java.InvocationMatcher; org.openrewrite.maven.table.MavenDownloadEvents) are also not included here, since they would be no-op string matches. They will be cleaned up in a separate PR on the commons side.

Validation

Locally: with this fix applied (and the equivalent fix already merged in moderneinc/moderne-recipe-loading-commons#70 for the parallel class used by moderne-worker v1), running io.moderne.java.spring.boot4.SpringBoot4BestPractices on a small (104 Java file) repo via mod CLI drops SourcesFileErrors from 111,767 rows to 4 rows. The remaining 4 are an unrelated K.Return.getPrefix() NPE in rewrite-kotlin.

Going forward

The two allowlists having drifted is the underlying anti-pattern. Worth tracking a long-term fix (single source of truth, generated allowlist from public method signatures, or CI lint) but out of scope for this PR.