Missing isPseudoAccount check in IOU/MPT payment paths (defense-in-depth gap)

[mvadari]

Issue Description

The XRP direct-payment path in Payment::doApply() has an explicit isPseudoAccount(sleDst) guard (line 584 of Payment.cpp):

if (isPseudoAccount(sleDst))
    return tecNO_PERMISSION;

The IOU and MPT payment paths have no equivalent explicit check. Instead, they rely on verifyDepositPreauth() (lines 415–418 for IOU, 485–488 for MPT) combined with lsfDepositAuth being set on pseudo-accounts to block unauthorized payments.

While this is not currently exploitable due to multiple independent layers of protection, it is a defense-in-depth gap that should be addressed for consistency and robustness against future code changes.

Steps to Reproduce

1. Examine src/libxrpl/tx/transactors/payment/Payment.cpp.
2. Note the explicit isPseudoAccount(sleDst) check at line 584 in the XRP direct-payment path.
3. Note the absence of an equivalent check in the IOU payment path (around line 415) and the MPT payment path (around line 485).

Expected Result

All three payment paths (XRP, IOU, MPT) should have an explicit isPseudoAccount check on the destination account, consistent with the XRP path and with other transactors like CheckCreate (which has isPseudoAccount(sleDst) in its preclaim).

Actual Result

The IOU and MPT paths rely solely on lsfDepositAuth + verifyDepositPreauth() to block payments to pseudo-accounts. This works today because:

1. createPseudoAccount() always sets lsfDisableMaster | lsfDefaultRipple | lsfDepositAuth.
2. The ValidPseudoAccounts invariant enforces these flags on every pseudo-account modification.
3. Pseudo-accounts cannot sign transactions (enforced by lsfDisableMaster, no regular key, and an explicit check in Transactor::checkSign when featureLendingProtocol is enabled), so they cannot create DepositPreauth entries.

However, if a future change were to inadvertently clear lsfDepositAuth on a pseudo-account or introduce a way for pseudo-accounts to authorize deposits, the IOU/MPT paths would become vulnerable while the XRP path would remain protected.

Environment

develop branch, current HEAD.

Supporting Files

N/A