Fix OAuth2ResourceServerLambdaDsl for Kotlin code

[MBoegers]

Summary

• Fix recipe to correctly handle Kotlin configuration code
• Prevent duplicate transformations when recipe runs multiple cycles
• Enable the previously failing Kotlin test

Problem

The OAuth2ResourceServerLambdaDsl recipe was incorrectly transforming Kotlin code. When run on Kotlin files like:

server.jwt().jwkSetUri("...").and().opaqueToken().introspectionUri("...")

The recipe would mangle the output, nesting opaqueToken inside jwt's lambda and losing the jwkSetUri configuration. The root cause was that after the first transformation cycle, subsequent cycles would incorrectly detect already-transformed methods (with lambda arguments) as still applicable for transformation.

Solution

1. Added a check in isApplicableMethod() to skip methods that already have a lambda argument, preventing duplicate transformations in subsequent recipe cycles
2. Enhanced isAndMethod() with fallback type checking using the select's method return type for cases where Kotlin return types aren't fully resolved

Known Limitation

The generated lambdas use parenthesized syntax .jwt({jwt -> ...}) instead of Kotlin's idiomatic trailing lambda syntax .jwt { jwt -> ... }. This is because the recipe creates J.Lambda (Java AST) nodes which print with parentheses in Kotlin.

A future improvement would be to detect Kotlin source files and create K.FunctionLiteral nodes instead, producing idiomatic trailing lambda syntax. The current output is valid Kotlin and functionally correct, just not stylistically ideal.

Test plan

• Existing Java tests pass (OAuth2ResourceServerLambdaDslTest.advanced())
• Kotlin test now passes (OAuth2ResourceServerLambdaDslTest.Kotlin.preservesCustomJwtConfiguration())
• Related recipes using ConvertToSecurityDslVisitor still work (HttpSecurityLambdaDsl, OAuth2ClientLambdaDsl, etc.)

Fixes moderneinc/customer-requests#1765