[rahul05ranjan]

Fixes #399.

The README documents that precision "takes precedence over round", but applyRounding() ran unconditionally before applyPrecisionHandling(), so:

• digits beyond round were lost before toPrecision() could keep them — filesize(2887, { precision: 4 }) printed 2.890 kB instead of 2.887 kB;
• boundary values were rounded twice — filesize(999499, { precision: 3 }): 999.499 pre-rounded to 999.5, toPrecision(3) then produced 1.00e+3, and the unit bumped to 1.00 MB instead of staying 999 kB;
• round leaked into the result even with precision set — filesize(1245, { precision: 2, round: 0 }) printed 1.0 kB instead of 1.2 kB.

The change: for decimal units (e > 0) with precision > 0, the un-rounded scaled value goes straight to the precision pass. Whole bytes (e === 0) still round to integers — a byte count is an integer quantity, and the sub-1-byte outputs (0 B, 0.0 B, 1 B) are unchanged.

Verification (node --test tests/unit/, no install needed — the tests import src/ directly):

• New regression test pins all four cases from the issue plus the two whole-byte controls. It fails on unpatched master@1a8566c (the 999 kB / 2.887 kB / 1.2 kB assertions) and passes with the fix.
• Full suite: 274 pass / 0 fail with the fix — every pre-existing precision pin (locale, sci-notation removal, standards, bits, array/object/exponent outputs, fullform) is unchanged.