feat(payload): finalize pending build on resolve

[0x00101010]

• Request cooperative finalization when a payload is resolved before its first build completes, allowing builders to seal accumulated work instead of discarding it.
• Preserve cancellation-on-drop semantics and existing builder behavior unless a builder observes the new signal.

[mattsse]

oh, right, I get the idea, but this is currently not wired yet to the basicjob, right?
maybe we can combine this so that we keep a cheap bool read like this

reth/crates/ethereum/payload/src/lib.rs

Lines 291 to 294 in 12d0cbc

	// check if the job was cancelled, if so we can exit early
	if cancel.is_cancelled() {
	return Ok(BuildOutcome::Cancelled)
	}

and only if this fires, we can check whether this is cancelled or needs to exist the tx loop and seal the block.
which makes me think that two bool atomics are fine here

cc @klkvr

[0x00101010]

oh, right, I get the idea, but this is currently not wired yet to the basicjob, right? maybe we can combine this so that we keep a cheap bool read like this

reth/crates/ethereum/payload/src/lib.rs

Lines 291 to 294 in 12d0cbc

	// check if the job was cancelled, if so we can exit early
	if cancel.is_cancelled() {
	return Ok(BuildOutcome::Cancelled)
	}

and only if this fires, we can check whether this is cancelled or needs to exist the tx loop and seal the block. which makes me think that two bool atomics are fine here

cc @klkvr

Correct—the signal is optional. Base will act on it to seal early, while the default Ethereum builder ignores it to preserve existing behavior.