`BasketItem.serialize` does not round its amounts, `Basket.serialize` does

[sveneberth]

Basket.serialize puts every basket-level amount through roundAmount; BasketItem.serialize puts none of the item amounts through it. Measured:

basket amountTotalGross: 0.3
item   amountGross     : 0.30000000000000004
item   amountDiscount  : 8.881784197001252e-16

roundAmount's own docstring names both hazards: the API truncates past four decimals, and json.dumps writes a near-zero residue in scientific notation, "not a number the API accepts".

This matters more since #13 documented that v3 reconciles totalValueGross == sum((amountPerUnitGross - amountDiscountPerUnitGross) * quantity) exact to the cent (API.600.410.062) — that guidance asks the caller to do exactly the arithmetic whose residue nothing scrubs. Spreading a 90.78 discount over 7 units gives 12.968571428571428 on the wire against a rounded total; the API truncates to 12.9685 and its own sum no longer matches.

Rounding was added deliberately at the basket level and looks simply forgotten at the item level. Suggested: route amountPerUnitGross, amountDiscountPerUnitGross, amountGross, amountVat, amountPerUnit, amountNet and amountDiscount through roundAmount the same way.

[sveneberth]

Measured belegt, mit ganz gewöhnlicher Arithmetik — this is not a corner case about float
residue.

Building a three-unit line the obvious way, amountVat=15.97 * 3, yields
47.910000000000004, and the API refuses the entire basket:

API.600.200.133  Amount 47.910000000000004 has more than 4 positions after the decimal point.

It surfaced by accident: it broke a sandbox probe I was writing for an unrelated question,
and the probe only worked after rounding every item amount by hand. Basket.serialize
would have absorbed exactly this through roundAmount; BasketItem.serialize does not.

So the practical impact is not a silently wrong basket in this case but a hard rejection of
a request whose arithmetic is correct to the cent — and one the caller cannot see coming,
since the basket-level amounts are handled for them. The error code is now named in
AGENTS.md next to the rounding rule (#19).