Skip UseMapOf when the anonymous HashMap is assigned to a concrete HashMap variable

[timtebeek]

Fixes #1148

Problem

For the anonymous-class form, UseMapOf replaced new HashMap<>() {{ put(..); }} with an immutable Map.of(..) but left the declared type untouched. When the variable was declared with the concrete type HashMap (rather than the Map interface), the result no longer compiled, since Map.of(..) returns an immutable java.util.Map that is not assignable to a HashMap variable:

private static final HashMap<String, String> VALUES = new HashMap<>() {{ put("key", "value"); }};
// became uncompilable:
private static final HashMap<String, String> VALUES = Map.of("key", "value");

Fix

Skip the anonymous-class rewrite when its result is assigned to a variable whose declared type is the concrete HashMap rather than the Map interface (option 2 in the issue). Beyond the assignability problem, widening the declared type to Map would also risk breaking later calls to HashMap-specific methods, so leaving such declarations untouched is the safer behaviour.

The guard checks the enclosing variable's declared type straight off the NamedVariable:

private boolean isAssignedToConcreteHashMap() {
    Object parent = getCursor().getParentTreeCursor().getValue();
    return parent instanceof J.VariableDeclarations.NamedVariable &&
            TypeUtils.isOfClassType(((J.VariableDeclarations.NamedVariable) parent).getType(), "java.util.HashMap");
}

The common cases — assigning to a Map-typed variable, returning, or using the value inline — are unaffected and still rewrite to Map.of(..). The mutable prose form (new HashMap<>(); x.put(..) → new HashMap<>(Map.of(..))) already stays a HashMap and so was never affected.

Tests

Added field and local-variable cases asserting that a concrete HashMap declaration is left unchanged (the field case mirrors the issue's reproducer with javaVersion(25)). Existing tests — including the Map-interface, LinkedHashMap/TreeMap, null-bail, and prose-form cases — continue to pass.