…customizer hides

Adds a `FirDeclarationGenerationExtension` (`RecipeFirMappedTypeFallbackExtension`) and an IR-phase body generator (`MappedTypeFallbackBodyGenerator`) to the rewrite-kotlin K2 plugin. Together they synthesize top-level extension functions that surface Java instance methods which Kotlin's `JvmBuiltInsCustomizer` allow-list hides from the mapped-type member scope.

## Why

Inside a `rewrite { ... } to { ... }` recipe-DSL body, an author writing `f.formatted("x")` (where `f: String`) hits `unresolved reference 'formatted'`. The same goes for `String.transform`, `String.stripIndent`, `String.translateEscapes`, and other JDK additions newer than the Kotlin mapped-type allow-list. The cause isn't this plugin — `RecipeFirDslCheckers` doesn't recurse into pattern lambdas (`RecipeFirDslCheckers.kt:226`) and `RecipeIrGenerationExtension` runs after FIR resolution — it's stock Kotlin behavior. `kotlin.String` is a mapped type; its descriptor lives in `kotlin.kotlin_builtins` and exposes only the Java members the customizer's compatibility allow-list lists. JDK 15+ additions, and various older shadowed methods on other mapped types, never made the list. Tracked upstream as [KT-52378](https://youtrack.jetbrains.com/issue/KT-52378) (open since 2022, still open in Kotlin 2.3.20).

This forces recipe authors to either cast through `java.lang.String` at every call site (`(f as java.lang.String).formatted(...)`) or avoid the methods. Both are friction points the plugin can remove without changing the recipe-author-facing DSL syntax.

## What changed

- `RecipeFirMappedTypeFallbackExtension.kt` (new, ~370 lines). A `FirDeclarationGenerationExtension` that walks `JavaToKotlinClassMap.mappedKotlinClassFqNames` (reflective field access — the property isn't public), and for each Kotlin↔Java pair iterates the Java class's `getDeclaredMethods()` to find public instance methods. For each, it generates a top-level extension function via `createTopLevelFunction` with the Kotlin counterpart as the extension receiver. JVM-erased dedup so `List`/`MutableList` collapse, and so `String.contentEquals(CharSequence)` doesn't collide with the `(Object)` overload.
- `MappedTypeFallbackBodyGenerator.kt` (new, ~184 lines). An IR phase, invoked from the existing `RecipeIrGenerationExtension`. Walks every `IrSimpleFunction`, identifies our synthesized extensions by origin string match (`MappedTypeFallbackKey`), resolves the Java counterpart class, looks up the matching `IrSimpleFunction` on it, and replaces the FIR-default stub body with `irReturn(irCall(javaFn, dispatchReceiver = irGet(extReceiver), valueArgs = ...))`. At JVM bytecode this is `invokevirtual` on the receiver — type-safe because `kotlin.String === java.lang.String` at JVM level.
- `RecipeFirExtensionRegistrar.kt` (+6 lines). Registers the new factory alongside `RecipeDslAdditionalCheckers`.
- `RecipeIrGenerationExtension.kt` (+6 lines). Invokes the body generator from the existing IR pass.
- `RecipeMappedTypeFallbackTest.kt` (new, ~171 lines). 6 tests covering fallback paths + a scope-isolation regression confirming Kotlin stdlib extensions still win where they previously did.

## Known caveats

Two gaps in this initial implementation, both addressable in follow-ups:

1. **Vararg sugar lost.** `Object...` parameters are emitted as plain `Array<Any?>` (non-vararg). FIR builder + FIR2IR have a round-tripping bug where `isVararg=true` with element type `Any?` trips `IllegalStateException: Vararg expression has incorrect type` during call-side IR construction. Workaround in `RecipeFirMappedTypeFallbackExtension.kt:303-318`. Practical impact: `f.formatted("x")` works; `f.formatted()` and `f.formatted("a","b")` need `f.formatted(arrayOf<Any?>(...))`. Bytecode is identical either way.
2. **Scope isolation not enforced.** Fallback extensions are globally visible whenever the plugin is on the classpath. `FirDeclarationGenerationExtension` doesn't expose a per-call visibility gate; `FirExpressionResolutionExtension` only adds implicit extension receivers and can't synthesize resolved callees for explicit-receiver calls. The tests document this and confirm that Kotlin stdlib extensions still outrank our synthesized top-levels on overload resolution (e.g. `String.indexOf(Char)` wins over `java.lang.String.indexOf(int)` outside `to { }`).

## Test plan

- [x] `:rewrite-kotlin:test` — 1235 pass, 16 skipped, 0 fail (no existing recipe test regresses)
- [x] `RecipeMappedTypeFallbackTest` — 6 new tests pass, including the scope-isolation regression
- [ ] Downstream consumer: `pattern_replace` MCP tool in moderne-cli successfully runs a Kotlin recipe whose `to { }` body calls `String.formatted(arrayOf<Any?>(...))`