Keep each sender's transactions in nonce order when selecting for a block

[alpenmilch411]

I came across a small correctness bug in Mempool.selectForBlock and wanted to send a fix.

What happens

When a block is built, selectForBlock picks transactions from the mempool. It correctly works out each sender's mineable run (their pending txs in nonce order), but then flattens everyone together and sorts the whole list by fee-per-byte. The comment there says the sort keeps each sender's txs in nonce order — but that only holds when two txs have the same fee-per-byte, which is the only time the nonce tie-break actually runs.

So if one account has two pending txs with different fees — say nonce 0 with a small fee and nonce 1 with a big one — the higher-fee nonce 1 sorts ahead of nonce 0. The returned list is then out of nonce order for that sender, and a block built from it fails to apply: applyTx requires tx.nonce === account.nonce, so it rejects nonce 1 (bad nonce (expected 0, got 1)) and the block is invalid.

It's easy to miss because every existing selectForBlock test uses a uniform fee, and the one cross-fee test uses two different senders — so the same-sender / different-fee case never comes up.

Minimal repro

One account at nonce 0, two pending txs:

• nonce 0, fee 200 (fee-per-byte 1)
• nonce 1, fee 100000 (fee-per-byte 657)

selectForBlock returns them as [nonce 1, nonce 0], and feeding that to applyBlockTxs fails with bad nonce (expected 0, got 1).

The fix

Keep each sender's nonce-ordered run together and order the senders by their best fee-per-byte, instead of sorting individual txs. A sender's txs then always go in nonce order, cross-sender fee priority is preserved, and a maxBytes cutoff just trims the tail instead of leaving a gap. Equal-fee senders get a deterministic tie-break so the template order is stable.

Tests

Added the same-sender different-fee case (the bug), a maxBytes truncation check that we keep the leading prefix, and an end-to-end test that runs the selected set through the real block path. All existing tests still pass.

Impact is low in practice — the miner notices the bad set and falls back to an empty block, so nothing invalid is broadcast — but selectForBlock is supposed to return a directly-mineable set, and right now it doesn't when a sender raises the fee on a later tx. Happy to adjust anything.