fix: Serialize MPToken UInt64 amounts as base-10 strings

[ckeshava]

Summary

The account_mptokens and account_mpt_issuances RPCs emitted MPToken amount fields as JSON numbers. Because many JSON parsers back numbers with IEEE-754 doubles, any value greater than 2^53 was silently rounded, so clients could not recover the exact on-ledger amount.

This change serializes the affected UInt64 amount fields as base-10 JSON strings, matching rippled's STUInt64::getJson behavior so Clio's output is consistent with the reference implementation:

• account_mptokens: mpt_amount, locked_amount
• account_mpt_issuances: maximum_amount, outstanding_amount, locked_amount

Changes

• Serialize the UInt64 amount fields via xrpl::STUInt64{field, value}.getJson(...) instead of inserting the raw integer into the JSON object, so the encoding matches rippled's string representation exactly.
• Add regression tests in both handlers asserting that large amounts (2^63 - 1, 2^53 + 1, and an odd value > 2^53) round-trip as exact strings.

Test plan

• New unit tests: RPCAccountMPTokensHandlerTest.LargeAmountsSerializedAsStrings and RPCAccountMPTokenIssuancesHandlerTest.LargeAmountsSerializedAsStrings.
• Existing MPToken handler tests updated to expect string-typed amount fields.

Notes

mpt_holders already serializes mpt_amount correctly via STUInt64::getJson; all other handlers that expose ledger UInt64 fields (e.g. vault_info, get_aggregate_price, gateway_balances) route through rippled's own serialization or STAmount, so they were already emitting strings and are unaffected.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ckeshava]

/ai-reviewer

[PeterChen13579]

You don't need to do this this PR, but I think this function along with setUint64IfPresent and in MPTHolders all do the same thing more or less. If this mpt_amount ever changes, there will be 3 places that needs to change. I think worth adding a helper to RPChelpers.cpp: something like:

boost::json::string
toBoostJsonString(xrpl::SField const& field, std::uint64_t value);

And all these 3 places can use it instead

[ckeshava]

yes, that makes sense. its good to have one common utility method.

[ckeshava]

Based on my search, I found only two similar utility methods: setUint64IfPresent (introduced in this PR) and the verbose code in MPTHolders RPC, both of which do identical tasks. I wanted to keep the diff of this PR as limited as possible, but it is a good idea to refactor them if there are more such usages.

[PeterChen13579]

LGTM, just left one comment

[godexsoft]

This PR seems to do what is needed. Let's just polish a bit and don't use obsolete names 👍

[godexsoft]

Same

[ckeshava]

thanks, updated in 26e2eae

[godexsoft]

So for this you used (1ULL << 63) - 1 and stuff like that. It of course works but it's even less readable now 😃
What i meant is use std::pow(2, 63) - 1. Note that they are constexpr only from c++26 so right now this would be a runtime call. Which is fine in tests and will become compile time for free when c++26 is used. Readability is more important than performance in tests.

[ckeshava]

that makes sense, I have updated this code in 8be75fb

[godexsoft]

Let's try std::pow etc., otherwise looks good 👍