5.9.5

Fixed

• ide_move_file keeps consumers compiling on a same-package cross-module move (#360) — moving a Java file between two modules (or source roots) that map the same package, the "extract com.example.pkg into its own artifact" workflow, leaves the class's fully qualified name unchanged, so a consumer's import com.example.pkg.*; is exactly as valid after the move as before. The IDE's move processor nevertheless re-binds every usage of the moved class, and that rewrite was reported to drop the wildcard import from consuming files, which then failed with cannot find symbol at the next build while the tool reported a clean success. The tool now snapshots, per file the move is about to rewrite, the imports that name the moved file's package and re-adds any that are gone afterwards (an on-demand import always; a single-class import only when the file has no wildcard for the package left, since the IDE legitimately folds single imports into one); because the package is unchanged, restoring an import restores the file's pre-move name resolution exactly. Every repair is reported in warnings. Moves that really change the package are untouched. On IntelliJ 2025.3 the platform itself keeps the import intact in this layout (a three-module reproduction of the issue now runs in the test suite and asserts a warning-free move), so the repair is a safety net for the IDE and plugin combinations that do drop it.
• ide_move_file warns when the destination is outside every source root — the other half of the same workflow: moving a source file into a directory that no module owns as a source root (a freshly created Maven/Gradle module the IDE has not imported yet) succeeded silently and the file dropped out of every module's sources, so builds and code intelligence stopped seeing it. The result now carries a warning naming the destination and pointing at ide_reload_project, ide_link_build_system, and ide_create_module.