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. Called at the top of both methods, before checkWeight. The echoed-back transaction is also set on the response builder at entry, so error paths return the truncated form too — 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.

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 and the error-message fix ensure clean, bounded, canonical responses on every code path.

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
• Full WalletTest, TransactionUtilTest, 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.