fix: wait for proposal timestamps to enter future window

[matthias-wright]

Addresses #254.

Fixes proposer timestamp selection when the parent timestamp is near the verifier future-window limit.

Changes:

• Wait before building a payload until parent.timestamp + 1 is acceptable under now + allowed_timestamp_future_ms.
• Keep child timestamps monotonic by selecting max(now, parent.timestamp + 1) after the wait.
• Add focused tests for wait and no-wait timestamp selection.
• Add unit tests.

[evonide]

The timestamp mismatch looks fixed. The proposer now waits until the required child timestamp is inside the verifier’s accepted future window before building the payload.

One follow-up concern is that the wait happens inside handle_proposal meaning a longer wait could keep the application actor from promptly handling other things like verify or certify messages. Is the assumption that this wait is always short enough in practice or should the wait be moved outside the actor path?

[matthias-wright]

That's a good point.
What if we check if the initial waiting time returned by proposal_timestamp_wait is larger than leader_timeout_ms, and if so, we abort immediately?

[sebastian-osec]

Yes, I think that makes sense. If the initial proposal_timestamp_wait is greater than the leader timeout, this proposal cannot become valid within the current leader window anyway, so aborting immediately avoids tying up the application actor.

The important part is that this should abort proposal creation, not bypass the timestamp wait. We should still only build once parent.timestamp() + 1 is inside the verifier future window.

[matthias-wright]

Update(c5dd562):

• Abandon proposal when timestamp wait exceeds leader timeout

[sebastian-osec]

Thanks. Looks good to me.