Read broker amounts at the precision the export actually uses

A real Scalable export reinvests a distribution as -29,579989728, and the
import refused the whole file: "broker record 14 has an invalid amount, require
signed 64-bit value with at most eight fractional digits". An amount is the
row's share count times its price, so it carries as many decimal places as the
two columns together need - nine here, from six places of shares and three of
price - and scalableMoney was computing its discarded remainder by parsing the
cell through the share-count parser, whose ceiling is eight. The leaked wording
"invalid quantity" for an amount cell was the tell.

Money cells are now read at arbitrary precision, rounded to money's four places
half away from zero, and the residue is accumulated exactly and reported as a
trimmed decimal. ScalableImport.Rounding stops being a domain.Quantity, which
carried the same eight-place ceiling, and becomes the exact decimal string it
always claimed to be; the JSON shape and the review copy are unchanged.

Share counts and prices are still refused beyond their own precision instead of
rounded. Rounding a share count misstates a holding, and rounding a price would
break the shares-times-price identity that every security row's amount is
checked against.

The reported row is now covered end to end: both legs of that distribution, the
single reference the broker reuses across them surviving deduplication, the
exact 0.000010272 residue, and the dividend paid in cancelling to the cent
against the units bought with it.

OPERATIONS.txt

@@ -444,11 +444,15 @@ action or depot transfer carrying a fee or tax, and any failed arithmetic check.
 A zero amount is accepted; it corrupts nothing, and a free share allocation is
 legitimately priced at zero.
 
-Money holds four decimal places and share counts hold eight. A reinvested
-distribution is quoted to six, so its amount is rounded half away from zero and
-the exact residue is reported in the import review and never hidden. A share
-count beyond eight places is refused rather than truncated, because a holding is
-verified against the broker's own figure.
+Money holds four decimal places and share counts hold eight. An amount is the
+row's share count times its price, so it carries as many decimal places as the
+two together need: a reinvested distribution in a real export reaches nine,
+past both. Amounts are therefore read at arbitrary precision, rounded to four
+places half away from zero, and the exact discarded residue is summed and
+reported in the import review rather than hidden. A share count or a price
+beyond its own precision is refused instead of truncated: rounding a share
+count misstates a holding, and rounding a price would break the shares-times-
+price check that the amount is verified against.
 
 Instruments are registered from the export, keyed by ISIN, with an ID derived
 from the ISIN so re-importing never creates a second entry for one security. One