bug: "skipping state transition processing due to pending txs" after "marked state transition batch as outdated"

[altergui]

something unexpected happened here, but it looks it was not handled correctly

and it went wild: now sequencer is stuck, even on other processes. On quick reading seems there's a transaction stuck at one of the RPCs, that same RPC is being used to calculate the nonce, and this makes it impossible to push any tx to other RPCs

[altergui]

so investigating i see there's effectively a stuck tx

https://sepolia.etherscan.io/tx/0x894c1667a457b9e5f499241d42eb2291b70b28a4a51f86311e7b762c0ff6d438

sequencer pushed it at 2026-03-12T10:41:02.225Z

but was never mined, so aggregated batches started piling up at the sequencer, here's the first one at 2026-03-12T10:47:06.017Z was queued up "skipping state transition processing due to pending txs"
so far so good, in a way

but then, at 2026-03-12T11:11:02.226Z a timeout was reached
failed to wait for state transition of 470d1ddc7ddceb0d818751d171d40366f010a3cc4691998b00000000000012: timeout waiting for id da8d2a88867161b82e7ab51a29520fd420b724ea2c22bf326efb8990b6d50024
and mayhem started. this should not happen.

[altergui]

1. if a statetransition tx is stuck, rather than simply timeout we should retry pushing it with a higher fee. (txs with blobs cant be cancelled, according to our own comments in code, haven't double checked)
2. we have a bug in the code, since a statetransition proof was done spite having pending txs;
3. also statetransition was based on a rootHashBefore that definitely did NOT come from the contract, this is another bug. statetransition should always be built on top of whatever rootHashBefore the contract currently has.

i'd say all this logic likely applies to results txs as well, so we should implement this at a common path for both.

[altergui]

likely related to #217