fix: attempt to send one flashblock if payload deadline is in the past

[akundaz]

📝 Summary

When the payload timestamp is in the past, the remaining time calculation now returns 0 instead of falling back to block time. This triggers an immediate flashblock build, giving us a change to at least get one out before the impending engine_getPayload call, which comes ~20-30ms after the FCU when it's this late.

💡 Motivation and Context

Observed timeline

16:03:34.844  FCU received with timestamp for second 34 (already 844ms in the past)
16:03:34.866  getPayload call arrives (only 22ms after FCU)
16:03:34.885  Next FCU with timestamp for second 35

With the old behavior, the scheduler would compute remaining_time = 1000ms (full block time) and schedule the first flashblock at ~170ms, which is well after getPayload arrives. This meant zero flashblocks could be emitted for that block and that the planned schedule would be misleading, since we'd miss all five planned flashblocks.

✅ I have completed the following steps:

• Run make lint
• Run make test
• Added tests (if applicable)

[sieniven]

@akundaz I am curious about the motivations here for this PR - why do we want to build 1 flashblock if FCU is already late? Often times this happens when the chain is catching up to protocol time - dont we want to simply build empty blocks (with optimism system tx) inside it?