Fix spurious overflow in Fraction.add/subtract for coprime denominators

[alhudz]

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

• 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.

---

Fraction.add/subtract go through addSub, whose d1 == 1 fast path (coprime denominators) builds the result numerator with mulAndCheck(numerator, fraction.denominator) and mulAndCheck(fraction.numerator, denominator). Those cross products overflow an int even when the reduced result is comfortably in range, so Fraction.getFraction(Integer.MAX_VALUE, 2).add(Fraction.getFraction(-Integer.MAX_VALUE, 1)) throws ArithmeticException: overflow: mul. Expected -2147483647/2, actual an exception. The sibling d1 != 1 branch already computes the numerator in wider precision and only rejects the final reduced value.

Compute the two cross products and their sum/difference in long (both denominators are positive and below 2^31, so the intermediate values cannot overflow long) and reject only when the resulting numerator does not fit an int, matching the wider branch. Keeping it inside addSub covers add, subtract and divideBy. The two helpers addAndCheck/subAndCheck were only used by this branch and are removed. Regression cases added to FractionTest fail with overflow: mul before the change.

[garydgregory]

Hello @alhudz

Isn't there a way to do this using Java's own java.lang.Math.addExact(int, int) and java.lang.Math.subtractExact(int, int), and so on?

[alhudz]

Makes sense, done. Used Math.toIntExact for the final numerator and Math.addExact/Math.subtractExact for the sum.

The one catch is the (int, int) variants can't sit on the cross products directly: u*v' and u'*v overflow an int even when the reduced result fits, which is the actual bug here. So each cross product is widened to long first, then the exact helpers do the add/subtract and toIntExact narrows back. FractionTest passes (35/35).

[garydgregory]

FYI I tested that the new tests fail without the main changes, merged 🚀 TY @alhudz