fix(api): bound and truncate api signatures

[Federico2014]

What does this PR do?

Hardens the two read-only signature APIs — getTransactionApprovedList (/wallet/getapprovedlist) and getTransactionSignWeight — against CPU exhaustion and oversized-signature echo-back.

1. Bound the recovery loop (CPU DoS)

Wallet.getTransactionApprovedList previously ran a hand-rolled unbounded ecrecover loop. Replaced by delegation to TransactionCapsule.checkWeight, matching getTransactionSignWeight. checkWeight rejects up front when sigs.size() > permission.getKeysCount(), before any signature recovery.

2. Reject excessive signature counts at entry

Both APIs now check trx.getSignatureCount() > getTotalSignNum() as the very first step, returning OTHER_ERROR / "too many signatures" immediately. This is a zero-cost guard that mirrors the bound already enforced by the consensus signature-verification path.

3. Truncate oversized signatures at entry

TransactionCapsule.truncateSignatures(trx) truncates any signature > 65 bytes to its first 65 bytes. The truncated bytes are copied out (ByteString.copyFrom(sig.substring(...).toByteArray())) rather than kept as a ByteString.substring view — a bounded view would still pin the original oversized backing array, so the copy lets it be released. Called at the top of both methods; the echoed-back transaction is set on the response builder at entry, so no path leaks untruncated signatures.

4. Harden checkWeight error message

weight == 0 path previously hex-encoded sig.toByteArray() (potentially oversized) into the exception message. Changed to the transaction hash (hash), a fixed 32-byte value that is more useful for debugging and cannot bloat error responses. This protects all callers of checkWeight, including consensus paths.

5. Keep the HTTP error path intact for result-only responses

The "too many signatures" early-return builds a result-only response with no transaction field. Util.printTransactionSignWeight / printTransactionApprovedList previously assumed transaction always exists, so on the HTTP servlet path they threw an NPE and the endpoint returned a generic servlet error instead of the intended OTHER_ERROR / "too many signatures". Both helpers now skip the nested-transaction rewrite when no transaction is present.

Why are these changes required?

getTransactionApprovedList was the only signature-recovery path without a bound on signature count. A single unauthenticated request with thousands of padded signatures could trigger unbounded ecrecover calls. Signature truncation, the memory-safe copy, and the error-message fix ensure clean, bounded, canonical responses on every code path — including the HTTP endpoints.

This PR has been tested by

• testApprovedListSigBound — signature within keysCount succeeds; exceeding keysCount rejected before recovery
• testApprovedListSigTruncate — 70-byte signature truncated to 65 bytes, signer still recovered
• testApprovedListTooManySigs — exceeding getTotalSignNum() rejected at entry with "too many signatures"
• testSignWeightSigTruncate — same truncation test for getTransactionSignWeight
• testSignWeightTooManySigs — same total-sign-num guard test for getTransactionSignWeight
• testPrintApprovedListTooManySigsHttpPath / testPrintSignWeightTooManySigsHttpPath — HTTP print helpers return the OTHER_ERROR / "too many signatures" JSON (no transaction field) instead of throwing
• Full WalletTest, TransactionUtilTest, UtilTest, RpcApiServicesTest — all green
• :framework:checkstyleMain, :framework:checkstyleTest — clean

Follow up

None.

Extra details

getTransactionApprovedList now delegates to checkWeight, applying the same permission semantics as getTransactionSignWeight. Behavioral changes:

• Too many signatures: the signature count exceeds permission.getKeysCount().
• Signature not in the permission: a recovered address is not one of the permission keys (weight 0).
• Duplicate signer: the same address signs more than once.

Callers that relied on the old "recover any signature" behavior to probe arbitrary signer addresses will see stricter results. No database, consensus, or config changes; read-only API paths only.

[3for]

LGTM now.

[halibobo1205]

LGTM.

[SHOULD] Please make sure this behavior change is called out in the release notes / API changelog, so SDK and client owners can adapt.