apollo_batcher: Add get_ts from mempool for echonet

[ron-starkware]

Note

Medium Risk
Touches consensus proposal timestamp selection and adds a new cross-component request/response variant; incorrect timestamps or integration mismatches could affect block info and downstream validation, though changes are scoped and include tests for the new FIFO behavior.

Overview
Adds a new batcher RPC/trait method get_ts (wired through BatcherRequest::GetTimestamp/BatcherResponse::GetTimestamp) that returns a mempool-sourced timestamp.

Updates consensus proposal building to optionally use this batcher-provided “original” timestamp in Echonet mode (renaming the flag to use_original_timestamp), falling back to local clock time on errors.

Adjusts Echonet FIFO mempool timestamp behavior so get_ts() returns the last returned timestamp when the queue is empty (instead of 0), adds TransactionQueueTrait::get_last_returned_timestamp, and includes a regression test for the empty-queue-after-drain case.

^{Written by Cursor Bugbot for commit 5ac1dd9. This will update automatically on new commits. Configure here.}

[reviewable-StarkWare]

This change is 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Zero timestamp used instead of clock fallback

Medium Severity

When the mempool queue is empty and no prior get_ts call was made, batcher.get_ts() returns Ok(0). The get_proposal_timestamp function treats this as a valid timestamp and returns 0 (Unix epoch) instead of falling back to clock.unix_now(). The old code using state sync would fall back to clock time when no data was available, since the if let Ok(Some(block_header)) pattern wouldn't match on Ok(None). The new code has no equivalent fallback because the mempool call always succeeds — the "no data" case is encoded as Ok(0) rather than as an error.

Additional Locations (1)

• crates/apollo_mempool/src/mempool.rs#L313-L317