Keep an aliased import's alias when ChangeType retargets it

[knutwannheden]

Motivation

ChangeType reuses an aliased import's alias when it retargets a type, so that import a.b.Original as MyAlias becomes import x.y.Target as MyAlias and references to MyAlias keep resolving (#3558, #3560). Verifying that behaviour across languages turned up three ways it goes wrong outside Kotlin.

In Python, imports can appear inside a function body or under if TYPE_CHECKING:. The alias capture considered every J.Import it visited, so such an import produced a file-level aliased import while the nested one stayed put and went on shadowing it wherever it applied. The file gained a line that changed no behaviour.

In Groovy, the alias was found but silently discarded on the way out: import java.util.ArrayList as MyList became import java.util.LinkedList, leaving MyList unresolved and the file broken.

Python's AddImport also treated a name bound by an existing import as a reference to that name, so only_if_referenced was satisfied by the import itself and a redundant second import was added.

Examples

Python keeps the alias, and usages need no rewriting:

# ChangeType("typing.List", "builtins.list")
from typing import List as L

def foo(items: L[str]) -> L[int]:
    pass

from builtins import list as L

def foo(items: L[str]) -> L[int]:
    pass

A function-local import is left alone. Previously the file gained a from builtins import list as L line above def foo, while the local import stayed and kept shadowing it inside the function:

# ChangeType("typing.List", "builtins.list") — output identical to input
def foo():
    from typing import List as L
    items: L[int] = []
    return items

The same holds for if TYPE_CHECKING:, where the added line would sit outside the guard that exists to keep the import off the runtime path:

# ChangeType("typing.List", "builtins.list") — output identical to input
from __future__ import annotations

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from typing import List as L

def foo(items: L[int]) -> None:
    pass

Groovy keeps the alias instead of dropping it:

// ChangeType("java.util.ArrayList", "java.util.LinkedList")
import java.util.LinkedList as MyList

class A {
    MyList type
}

Summary

• Restrict ChangeType's alias capture to imports with no enclosing J.Block. Java, Kotlin, and Groovy have no nested imports and are unaffected; Python's function-local and if TYPE_CHECKING: imports are now skipped, since the file-level import that would replace them binds a wider scope than the original.
• Set the alias on the J.Import that Java's AddImport constructs. It has reached the visitor since Update AddImport with alias to support Kotlin alias import #3560 — threaded through maybeAddImport/addImportVisitor so Kotlin's own AddImport could receive it — but was never applied to the import Java's implementation builds, so Groovy lost it. JavaPrinter emits no alias, so a Java file prints identically whatever the import holds. The non-aliased add that ChangeType also queues is skipped, because by then the type is explicitly imported.
• Ignore identifiers inside import statements in Python's AddImport reference check, matching RemoveImport's collector and Java's AddImport.

Test plan

• New Python RPC tests in tests/rpc/test_java_recipes.py covering the aliased from-import, a re-exported import named by its canonical type (collections.abc.Iterable is attributed typing.Iterable), the standalone import <module> as <alias> statement, and the function-local and if TYPE_CHECKING: imports left unchanged. Both nested cases were confirmed to fail without the guard.
• New Groovy changeImportKeepsAlias in ChangeTypeAdaptabilityTest, which fails on main and passes here.
• New test_add_import.py case for a name occurring only inside an import statement.
• Full module suites, all green: rewrite-java-test (2167 tests), rewrite-kotlin (1309, including changeImportAlias, changeTypeWithGenericArgumentAlias, addImportAlias, updateImportAlias), rewrite-groovy (678), and Python (1803 across tests/python, tests/recipes, tests/rpc).
• RequirementsTxtParserTest.markerContainsDependenciesFromFreeze fails on this branch, but fails identically on a clean checkout of main — it resolves live packages from PyPI and is unrelated to these changes.