Add TypeNameMatcher to RecipeClassLoader allowlist

[pdelagrave]

Problem

RecipeClassLoader.PARENT_DELEGATED_PREFIXES includes org.openrewrite.java.internal.TypesInUse so that recipes and the host (e.g. mod CLI, recipe worker) agree on a single shared TypesInUse Class. The signature of TypesInUse.hasTypeMatching was recently extended with a new parameter type org.openrewrite.java.TypeNameMatcher, but TypeNameMatcher was not added to the allowlist.

When a recipe-loaded UsesType.visit() invokes TypesInUse.hasTypeMatching(TypeNameMatcher, boolean):

• UsesType is loaded by the recipe classloader, which resolves TypeNameMatcher to its own copy from the recipe artifact's bundled rewrite-core.
• TypesInUse is loaded by the parent classloader, which resolves TypeNameMatcher to the parent's copy.
• The JVM enforces a loader constraint and throws java.lang.LinkageError because the two classloaders disagree on TypeNameMatcher's Class identity.

The error fires once per (recipe instance, source file) pair, with each row writing a multi-KB stack trace to the SourcesFileErrors data table. On Spring-heavy runs this can produce hundreds of MB of error rows per repo.

Solution

Add org.openrewrite.java.TypeNameMatcher to PARENT_DELEGATED_PREFIXES. Both classloaders then resolve TypeNameMatcher via the parent and share a single Class object, satisfying the loader constraint.

Validation

Validated locally:

	Before fix	After fix
SourcesFileErrors rows	111,767	4
SourcesFileErrors.csv.gz size	1.5 MB	608 bytes
LinkageError rows	111,763	0

(The 4 remaining rows are an unrelated K.Return.getPrefix() NPE in rewrite-kotlin, not affected by this change.)

The same one-line fix is also being submitted to the parallel io.moderne.recipe.RecipeClassLoader in moderneinc/moderne-recipe-loading-commons for the v1 worker path.