fix: carry filesize suffix when mantissa rounds up to base

[patchwright]

Problem

All three public functions (traditional, binary, decimal) can produce impossible output like "1,024.0 KB" instead of "1.0 MB" for values just below a unit boundary.

Root cause: _to_str picks the suffix from the unrounded value, then formats the mantissa — which can round up to base, producing an impossible result.

filesize.decimal(999_999)        # '1,000.0 kB'  ← should be '1.0 MB'
filesize.traditional(1024**2-1)  # '1,024.0 KB'  ← should be '1.0 MB'
filesize.binary(1024**2-1)       # '1,024.0 KiB' ← should be '1.0 MiB'

Fix

Convert suffixes to a list before the loop. After computing the mantissa, round and compare against base. If the rounded value hits base, step up one suffix and recompute:

mantissa = base * size / unit
if round(mantissa, 1) >= base and i - 1 < len(suffixes):
    suffix = suffixes[i - 1]
    mantissa = size / unit

Math: when the current unit is base**i, dividing size by that same unit gives the value in the next suffix (whose denominator is base**(i+1), which divides into base * size / base**(i+1) = size / base**i = size / unit).

Also removes the existing TODO comment that flagged this exact issue.

Tests

Added test_rollover_decimal, test_rollover_traditional, and test_rollover_binary covering the unit boundaries for all three functions.

[lurch]

Ahhh, the fun of floating-point rounding 😆

I wonder if it might also be worth adding some unit-tests for the boundary-values? E.g.

>>> traditional(1996)
'1.9 KB'
>>> traditional(1997)
'2.0 KB'
>>> decimal(1950)
'1.9 kB'
>>> decimal(1951)
'2.0 kB'
>>> binary(1996)
'1.9 KiB'
>>> binary(1997)
'2.0 KiB'

[patchwright]

Good call, those within-unit boundary cases are worth pinning down separately from the rollover ones. Added a test_rounding_boundaries covering your exact examples for all three functions:

traditional(1996) == "1.9 KB"
traditional(1997) == "2.0 KB"
decimal(1950)     == "1.9 kB"
decimal(1951)     == "2.0 kB"
binary(1996)      == "1.9 KiB"
binary(1997)      == "2.0 KiB"

All pass on the branch. Thanks for the review.

[lurch]

Is it also worth checking the boundaries at e.g.

>>> decimal(999_949)
'999.9 kB'
>>> decimal(999_950)
'1.0 MB'

or do you think those are sufficiently covered by the existing tests?

[patchwright]

Good catch. Those weren't covered: test_rollover_decimal only pinned the far end at 999_999, and test_rounding_boundaries is within-unit, so the first-flip at 999_950 had no test. Both behave as expected: decimal(999_949) stays '999.9 kB', decimal(999_950) rolls to '1.0 MB'.Added that pair. traditional and binary share the same carry logic and had the same gap (their rollover tests only checked 1024**2 - 1), so I pinned their first-flip too: 1_048_524 stays '1,023.9 KB'/'1,023.9 KiB', 1_048_525 rolls to '1.0 MB'/'1.0 MiB'. Pushed in the latest commit, full suite green.