Kotlin recipe DSL: type the matcher's parameters, not just their count

[timtebeek]

• The K2 plugin built its MethodMatcher spec with List(jvmArgCount) { "*" }, so a rewrite { x: Double -> Math.abs(x) } recipe's declared Double reached the after-template but not the matcher (java.lang.Math abs(*)) and every same-arity overload matched — with Math.round, whose (double) overload returns Long and (float) returns Int, that turned fun r(x: Float): Int = Math.round(x) into a Long assigned to an Int. Kotlin recipe DSL: emit precise arg-count matcher patterns instead of (..) #7737 scoped itself to arity and rewrite-kotlin: variadic-by-default matching in the recipe DSL #7895 already types the varargs branch's fixed prefix, so this just brings the non-varargs branch in line.

Naming types outright is unsafe because KotlinTypeMapping only remaps Kotlin builtins to their JVM FQN for Java-declared methods — the same String parameter reads java.lang.String on a Java-declared callee and kotlin.String on a Kotlin-declared one, and authors routinely write Kotlin stand-in classes for Java targets — so reference builtins emit a package-wildcard token (*..String) that names both spellings, primitives emit the JVM keyword, and anything unpredictable (type parameters, nullable primitives, value classes, nested classes, the kotlin. package, the lifted extension-receiver slot) keeps the old *.

Four new tests in RecipePluginRewriteTest cover the narrowed match, an untargeted sibling overload left alone, the Math.round miscompile, a Kotlin-declared callee, and the kotlin-recipe-starter recipes still firing; all four fail without the change, and one existing spec assertion moves from substring(*, *, *) to substring(*, int, int).

Verified downstream against moderneinc/recipes-kotlin (964 tests, 244 DSL recipes): green, and its UseDoubleRoundToLong/UseFloatRoundToInt pair plus three same-arity Math.floorMod recipes were silently cross-matching before this.

[timtebeek]

Downstream check: moderneinc/recipes-kotlin

Measured against recipes-kotlin@origin/main (9ba907e) by publishing both builds to mavenLocal and running the full suite against each. The only harness edit is pinning rewriteVersion to the locally published 8.92.0-SNAPSHOT; nothing else in the repo is touched.

No regressions:

	tests	failures
baseline	964	0
with this change	964	0

Green both ways — but that's because each recipe's test only exercises its own overload, so the over-match is invisible to them. Dumping the generated MethodMatcher specs out of the compiled $KtRecipe classes from each run shows what actually changed:

recipe	baseline	with this change
UseDoubleRoundToLong	Math round(*)	Math round(double)
UseFloatRoundToInt	Math round(*)	Math round(float)
UseIntMod / UseLongMod / UseLongModInt	Math floorMod(*,*) ×3	(int,int) / (long,long) / (long,int)
UseIntFloorDiv / UseLongFloorDiv	Math floorDiv(*,*) ×2	(int,int) / (long,long)
UseAppendLineChar / …CharSequence / …WithValue	StringsKt appendln(*,*) ×3	(*,char) / (*,*..CharSequence) / (*,*..String)
UseCharLowercaseCharForCharacter	Character toLowerCase(*)	(char)
UseLowercaseWithLocale	StringsKt toLowerCase(*,*)	(*,java.util.Locale)

The round pair is the type-unsafe collision this PR is about: two recipes sharing one matcher but with incompatible after-templates (roundToLong returns Long, roundToInt returns Int), so whichever ran first miscompiled the other's call sites.

One collision survives by design. UseAppendLineAny stays appendln(*,*) and still overlaps the three appendln siblings — kotlin.Any and java.lang.Object share no simple name, so no single token matches both parsers' spellings.

Suggested follow-up for that repo: a test that runs the composite over a source holding several overloads at once. The per-overload tests they have now pass whether or not the matchers collide.