apexToLovelace's own unit tests prove the helper is exact, but nothing
proved any of its 5 call sites actually invoke it - reverting
buildSendApex's call site to Math.floor(amountApex * 1_000_000) left the
full build suite at 26/26 green, because every existing amountApex/
apexAmount/stakeApex fixture is a whole integer.
Adds one call-site pin each for buildSendApex, buildSendTokens' apexAmount
path (both build.test.ts), and buildEndorse (gov-build.test.ts, the
simpler of the two stake fixtures), each using a fractional amount
confirmed via node -e to actually lose a lovelace under the old
Math.floor path, decoding the built tx and asserting the recipient/script
output's coin is the exact expected lovelace. buildSendTokens needed its
own defect value (1.005 AP3X undershoots this output's min-UTxO once it
carries a native asset, an unrelated ledger rule) - reused buildEndorse's
verified 8.03 AP3X instead. buildCritique and buildProposalLock's call
sites are structurally identical to buildEndorse's and already covered by
apexToLovelace's own exhaustive unit tests; one representative call-site
pin plus the two build.ts sites is the load-bearing set, not all five.
Proved each pin load-bearing by reverting its call site to Math.floor one
at a time: each mutation failed exactly the matching test (naming the lost
lovelace: 1004999 vs 1005000, 8029999 vs 8030000, 8029999 vs 8030000) and
no other test, then was reverted byte-identical (confirmed via git diff).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
08d6954049