Improve Sequence Allocation for Includer's XRPL Transactions

[themicp]

Context

Related to #30.

When submitting transactions to the XRP Ledger, each transaction must use a unique and strictly increasing Sequence number for a given account. The XRPL node enforces that only one transaction per (account, sequence) may be queued at a time.

A problem arises if:

• The includer submits a transaction with sequence N and receives a terQUEUED response (i.e. the transaction is accepted but pending).
• Before that transaction is included or dropped, the includer submits another transaction and unknowingly reuses the same sequence N.
• This can result in:
  • The second transaction replacing the first if it has a higher fee, or
  • A rejection (telCAN_NOT_QUEUE_FEE) if the fee isn't high enough.

To prevent this, we need a mechanism that guarantees the includer never reuses a pending sequence number for the same account unless doing so intentionally.

Goal

Implement a sequence allocator that:

• Returns the next safe Sequence number for a given account.
• Prevents accidental reuse of pending sequence numbers.

Proposed Design

1. Check for existing queued/submitted transactions in Postgres.
2. If there are no pending transactions for the account:
   • Use account_info().account_data.Sequence as the base. (default behavior of .prepare_transaction())
3. If there are pending transactions:
   • Use MAX(sequence) from queued_transactions (with FOR UPDATE) to compute the next safe sequence.