Fix intword() rounding carry for values >= 10^24

[Sreekant13]

Fixes #400.

intword()'s rounding carry (so 999_999 reads as "1.0 million", not "1000.0 thousand") silently stopped firing from septillion (10^24) upward:

>>> intword(10**24 - 1)   # was '1000.0 sextillion'
'1.0 septillion'
>>> intword(10**33 - 1)   # was '1000.0 nonillion'
'1.0 decillion'

Cause

The carry compared a float product against an exact int power:

if not largest_ordinal and rounded_value * power == powers[ordinal + 1]:

powers holds Python ints, and float(10**k) != 10**k once k >= 24, so 1000.0 * 10**21 == 10**24 is False and the carry was skipped. Below 10**24 the intermediate is float-exact, so it worked, which is why it went unnoticed.

Fix

Compare the rounded mantissa against the integer ratio between adjacent powers:

if not largest_ordinal and rounded_value >= powers[ordinal + 1] // power:

Every entry in powers is a power of ten, so the ratio is exact. It stays large (10**67) across the decillion-to-googol gap, so 10**36 is still "1000.0 decillion" and the #356 behaviour is unchanged.

Tests

Added 10**24 - 1 ... 10**33 - 1 to the test_intword table (all four fail on main, showing "1000.0 <smaller unit>"), plus the existing 10**36 -> "1000.0 decillion" case kept right after them as the control that the gap is untouched. Full test_number.py passes (236), and the existing small-number carries (999_999 -> "1.0 million", etc.) are unaffected.

[Sreekant13]

Closing as a duplicate of #346, which fixes this same intword() carry bug and predates this PR by two months. Apologies for the dup: I missed #346 in my search before opening.

For what it is worth as an independent confirmation for reviewers: I reproduced the exact same boundary (the carry fails from 10^24 through 10^33, works below because float(10**k) is exact for k < 24), and #346's fix (rounded_value == powers[ordinal + 1] // power) plus its controls for the 10^36 decillion-to-googol gap and the googol case all hold. #346 looks correct and complete to me.