Find NaN in ArrayUtils.lastIndexOf for double and float arrays

[alhudz]

Repro: ArrayUtils.lastIndexOf(new double[]{Double.NaN}, Double.NaN) returns -1, while ArrayUtils.indexOf on the same array returns 0 (and contains returns true).
Cause: indexOf(double[])/indexOf(float[]) were given explicit NaN matching (the indexOfNaN helper for double, a searchNaN flag for float), but the lastIndexOf overloads still only compare with valueToFind == array[i], which is never true for NaN.
Fix: route the two double lastIndexOf overloads (with startIndex, and with startIndex+tolerance) through a new private lastIndexOfNaN helper that mirrors indexOfNaN, and add the same searchNaN check to lastIndexOf(float[], float, int), so lastIndexOf agrees with indexOf on NaN.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

@alhudz

Would you please add tests for:

• java.lang.Double|Float.NEGATIVE_INFINITY
• java.lang.Double|Float.POSITIVE_INFINITY

Thank you!

[alhudz]

Done. Added testLastIndexOfDoubleInfinity and testLastIndexOfFloatInfinity covering POSITIVE_INFINITY and NEGATIVE_INFINITY across the overloads, with each infinity appearing twice so the tests pin the last-occurrence index. Both infinities already matched via == (and the tolerance path), so this is test coverage only, no runtime change there.