[wozhenbang2004]

This follows up on the native Type interoperability covered by #3512.

WildcardTypeImpl and GenericArrayTypeImpl compare equal to the corresponding JDK reflection types, but currently return different hash codes. This can miss an exact TypeHandlerRegistry registration: a native List<String>[] registration is not found with the equal resolved type. For wildcard List types, a lookup can fall back to a conflicted raw-List handler when another specialization is registered.

The change aligns the two hash-code implementations with their JDK counterparts, without changing equality or type resolution. The existing equality tests now check hash-code consistency too; wildcard coverage includes upper bounds, lower bounds, and unbounded wildcards.

Validation:

• The updated resolver suite has 4 expected failures against the unpatched source and passes all 47 cases after the fix on JDK 17 and 21. A separate public-API registry/reflection probe goes from 8 failing assertions plus 2 passing controls to 10/10 passing.
• Fork validation run 41033589160 passed on Temurin 25 / Ubuntu: formatter:validate impsort:check and the official Linux command ./mvnw test --batch-mode --no-transfer-progress --show-version -Dlicense.skip=true -PtestContainers.
• The full Maven run reported 2,061 tests, 0 failures, 0 errors, and 19 existing project skips. The resolver suite ran all 47 cases with no skips, including the three wildcard variants and the generic-array regression.
• The fork workflow checked out upstream bd5915a99761da58011922d4ce143f840a805cc3, applied the exact patch, and verified both patched source hashes again after the tests.

The macOS/Windows matrix has not been run for this patch.

[coveralls]

coverage: 87.454% (+0.004%) from 87.45% — wozhenbang2004:fix/resolved-type-hash-contract into mybatis:master