Fix fractional() emitting degenerate output when the fraction rounds to a whole

[semx]

Noticed while probing edge cases: fractional() emits degenerate output when the fractional part rounds to a whole number.

>>> import humanize
>>> humanize.fractional(2.9999999)
'2 1/1'        # expected '3'
>>> humanize.fractional(0.9999999)
'1/1'          # expected '1'
>>> humanize.fractional(0)
'0/1'          # expected '0'

Cause

After frac = Fraction(number - whole_number).limit_denominator(1000), when the fractional part reduces to a whole number the denominator is 1 (numerator ∈ {-1, 0, 1}). The existing special case only handled numerator == 0 (a plain integer input like 1.0), so:

• numerator == 1 (the fraction rounded up to 1/1) fell through to the mixed-fraction branch → "2 1/1";
• fractional(0) produced "0/1".

Changes proposed in this pull request:

• Fold any whole-valued fractional part (denominator == 1) into the integer part, so the result reads as a normal integer.
• Add regression tests for 0, 0.0, 2.9999999, 0.9999999, -2.9999999.

All existing tests pass (705 passed); ruff and black clean.

[semx]

Gentle ping. This fixes fractional() emitting degenerate output (a whole number rendered as "2 1/1") when the fraction rounds to a whole; it now returns the plain integer, with tests for the boundary cases. docs and pre-commit.ci are green. Let me know if any change would help it land. Thanks!

[MohammedAlkindi]

Ran this on Windows 11, CPython 3.14.7, fresh clone.

On main (ce4147b): fractional(2.9999999) → '2 1/1', fractional(0.9999999) → '1/1', fractional(0) → '0/1', fractional(-2.9999999) → '-2 1/1' — reproduces exactly as described.

On this branch (0fe540d): the same inputs give '3', '1', '0', '-3'. I also checked cases the PR doesn't list: -0.9999999 → '-1' (the whole_number + numerator fold handles the negative-numerator case correctly), string inputs '2.9999999' → '3' and '0' → '0', 1000.9999999 → '1001', and nan still passes through as 'NaN'.

Applying the new test rows to main's number.py gives 5 failures with the expected assertions (e.g. assert '1/1' == '1'), so the tests do pin the bug. Full suite: main 715 passed / 74 skipped, branch 720 passed / 69 skipped; the skip difference is only because this branch predates the si_LK locale on main — cherry-picking 0fe540d onto current main is clean and gives 720 passed / 74 skipped.

One cross-reference for the maintainers: this change also covers what #351 and #374 fix (fractional(0) → '0/1'), plus the 1/1 carry case those don't handle, so merging this would supersede both.

Limits: I tested on 3.14.7, not the full CI matrix, and didn't run lint/mypy.