[henriquejsza]

What's changed?

UseMapOf recognises two input shapes: the anonymous-class form
(new HashMap<>() {{ put(k, v); ... }}) and the prose new HashMap<>() + put(..)
chain. Both could emit a Map.of(..) / Map.ofEntries(..) call that throws at
runtime where the original HashMap did not:

• The anonymous-class form only skipped a put when an argument was the literal
  null. A nullable parameter or method-call value (as in the issue's
  put("owner", dataOwner)) was still folded into Map.of(..), which throws
  NullPointerException per JEP 269.
• Neither form checked for duplicate keys. Two puts with the same key produced a
  Map.of(..) / Map.ofEntries(..) call that throws IllegalArgumentException,
  where a HashMap.put(..) chain had just kept the last write.

This change:

• Reuses the prose form's isProvablyNonNull check for the anonymous-class form,
  so both forms only convert when every key and value is statically known to be
  non-null.
• Bails both forms when two keys that can be compared statically
  (SemanticallyEqual) are equal.
• Teaches isProvablyNonNull to also accept an initialized static final
  constant, so existing conversions with a constant key (e.g. put(BLAH, "foo"))
  keep working rather than regressing under the stricter nullability guard.

The safe cases the recipe converts today are unchanged.

What's your motivation?

Fixes #1307.

Anything in particular you'd like reviewers to focus on?

• The duplicate-key guard uses SemanticallyEqual.areEqual(..) on the key
  expressions, so it only rejects keys it can prove equal (identical literals,
  identical constant references); genuinely distinct runtime values are still
  converted.
• Extending isProvablyNonNull to accept static final + HasInit fields keeps
  the pre-existing changeDoubleBraceInitForNonStringTypes behaviour; let me know
  if you'd prefer a narrower condition.

Any additional context

This issue is cross-referenced from the recipe-quality tracking issue #1330 (item
D1). It is scoped to the null-value and duplicate-key hazards only; the
large-map / maxEntries concern (#1310) is handled separately in #1368.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've run ./gradlew build locally, and committed any resulting changes to recipes.csv
• I've formatted the lines I changed, without reformatting code I didn't touch