SONARJAVA-6777: Implement S9401: IdentityHashMap keys should not be boxed primitive types - #6152

📄 java-checks/src/test/java/org/sonar/java/checks/IdentityHashMapBoxedKeyCheckTest.java:19-22 📄 java-checks/src/test/java/org/sonar/java/checks/IdentityHashMapBoxedKeyCheckTest.java:50-58
java-checks-test-sources/default already declares Guava (32.1.1-jre, provided scope), so TestClasspathUtils.DEFAULT_MODULE.getClassPath() alone resolves com.google.common.collect.Maps — this is how the existing Guava sample test works (BigDecimalEqualsCheckTest.test_guava uses no custom classpath). Appending Maps.class's code source here adds the java-checks test-scoped Guava (33.7.1-jre per the root pom dependencyManagement) on top of 32.1.1-jre, so ECJ analyses the sample against two Guava jars and silently resolves whichever comes first; the test only passes because both versions still declare newIdentityHashMap(). Drop the manual classpath (and the Guava import/URISyntaxException) to match the established pattern.

📄 java-checks/src/main/java/org/sonar/java/checks/IdentityHashMapBoxedKeyCheck.java:33 📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S9401.html:7-19
The reported message tells the developer to "Use a non-boxed key type", but the rule description's remediation and its compliant example fix the defect by changing the map implementation (new HashMap<>() with the same Integer key). Since map keys can never be primitives, a user acting on the message alone is pointed away from the documented fix; align the message with the description, e.g. mention using a map that compares keys by value (the sample's {{...}} assertion on line 20 of IdentityHashMapBoxedKeyCheckSample.java must be updated too).

• ✅ Implement S9401 rule to check that IdentityHashMap keys are not boxed primitive types