fix(tempo): coordinate parallel sponsor fee exposure

[gakonst]

What changed

• replace sender-level serialization with a sponsor-wide atomic fee budget
• key the budget by the recovered on-chain sponsor address, independent of replay-store prefixes
• persist the final sponsor-signed transaction hash and an owner-fenced lifecycle (prepared → broadcasting → pending)
• keep broadcast/pending exposure reserved until a receipt is observed or the expiring nonce reaches validBefore
• reconcile receipts lazily before admitting more work; stale workers cannot release replacement reservations
• bound both aggregate declared fee exposure and reservation count
• wait for capacity until the payment challenge deadline rather than rejecting parallel expiring-nonce submissions

Why

Tempo expiring nonces are designed for independent transactions to be submitted in parallel. A sender mutex defeats that property, while releasing budget immediately after an optimistic RPC response fails to bound transactions that are still pending or whose response was lost.

This keeps the aggregate sponsor bound without coupling independent senders or same-sender expiring-nonce transactions. The final signed hash and owner token provide the useful lifecycle/reconciliation pieces discussed in #690; this PR intentionally does not take #690’s sender lock or add a manual recovery API. It supersedes #690 for this behavior.

Tempo references:

• https://docs.tempo.xyz/guide/payments/send-parallel-transactions
• https://docs.tempo.xyz/protocol/transactions

Policy

tempo.charge({ feePayerPolicy }) accepts:

• maxInFlightTotalFee: aggregate declared worst-case fee exposure; defaults to maxTotalFee * 10
• maxInFlightReservations: count bound protecting the budget from zero/low-fee request amplification; defaults to 100

Per-transaction fee validation remains in the shared fee-payer policy. The aggregate settings are charge-broadcast policy and do not leak into session fee-payer configuration. A single transaction larger than the aggregate budget is rejected immediately instead of waiting until expiry.

Capacity waiters perform atomic no-op reads while full. A challenge expiry stops a waiter from beginning new work, but an already broadcast reservation remains counted through the transaction’s later validBefore boundary.

Validation

• reproduced the previous same-sender rejection on pristine main
• verified concurrent same-sender expiring-nonce transactions succeed
• verified different senders sharing one sponsor coordinate against the same atomic budget
• verified capacity waits and proceeds after terminal receipt reconciliation
• verified optimistic sponsored broadcasts remain persisted as pending
• verified owner fencing rejects stale transitions/releases
• verified reservation-count limiting and oversized-transaction rejection
• local Tempo node: 180 focused fee-payer/charge/budget tests passed
• pnpm check:ci
• pnpm exec tsgo -b
• pnpm build

Both commits are SSH-signed for GitHub verification.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/mppx@699

commit: a034bbe

[parvahuja]

outside of the edge case above, i think 👍