Holocene-D: BatchQueue/Stage improvements tracker

[sebastianst]

Collecting follow-up work related to or discovered during #12417

Blocking

• remove l1 origin update assertion on single increments after confirmation/disproving
• Holocene-D: Pending safe promotion only after full L1 block derivation #12695
  The pending safe head should only be promoted to safe after all batches have been fully derived from any given L1 origin. Otherwise nodes that restart mid-way through derivation can be made to chain split by a malicious batcher. Will write down more details soon, but this is very hard to exploit. This becomes more important with Holocene because overlapping span batches aren't fully validated any more. But it is also possible pre-Holocene with channels full of singular batches, which a malicious batcher has the freedom to choose.

Non-blocking

• Revisit empty batch generation when sequencer window runs out.
  Empty batch generation currently advances the l1Block after all empty batches for an epoch have been generated. It may be better to generate the next epoch's block at the right time and then let the existing updateOrigin take care of epoch advancing.
• Revisit originBehind definition.
  An origin is currently only considered behind if it's strictly before the parent's L1 origin. However, it may make sense to change the definition to also include equality. This makes sense because no new batches can be included in the parent's L1 origin block.
• Use a span batch iterator instead of generating all singular batches at once. This makes particularly sense for Holocene, where we don't backwards-invalidate but only forwards-invalidate.
• Revisit BatchUndecided status of batches.
  It is usually used in cases where not enough l1Blocks are available yet. However, when we reset to a safe block's l1 origin and start deriving from it, the origin block itself cannot contain any new batches. So when we are at the point of checking batch validity, we have advanced the L1 origin at least one block, so we should always have 2 L1 blocks available. So I believe this status can be removed altogether. This is already asserted in BatchStage.NextBatch. It is also used during overlapping span batch validation if the l2fetcher hits an error. This can be handled differently, in a clearer way.
• Improve overlapping span batch validation. The l2fetcher fetches full blocks and compares full transaction content. This can probably be improved to work only with MHT roots and headers.

[sebastianst]

The l1 origin update assertion on single increments got disproven by the testCrossLayerUser tests in op-e2e/actions/helpers/user_test.go. They panicked at the assertion. So even after Holocene, we sometimes see origin jumps larger than 1 during updates in the batch queue.