Add reader-node-start-block-timestamp gating across reader-node ingestion paths

[Copilot]

We currently gate reader-node ingestion by block number only. This change adds timestamp-based start gating so deployments can start exactly at hardfork boundaries by emitting only blocks with timestamp >= configured start timestamp.

• New reader-node start timestamp input

  • Adds --reader-node-start-block-timestamp to reader-node config.
  • Supports:
    • Unix seconds
    • RFC3339 / RFC3339Nano
  • Parsing is centralized in cmd/apps/reader_node_start_block_timestamp.go.

• Timestamp gate wired through all reader-node modes

  • Standard reader-node pipeline
  • reader-node-stdin
  • reader-node-firehose
  • Config propagation was added to app config structs and NewMindReaderPlugin(...) call sites.

• Inclusive start semantics (>=)

  • Gate drops only blocks strictly before the configured timestamp.
  • Blocks exactly at the configured timestamp are accepted (aligned with hardfork boundary use-cases).

• Focused coverage for parser + boundary behavior

  • Adds parser tests for empty, unix, RFC3339, and invalid values.
  • Adds mindreader gate test to validate:
    • start - 1s is skipped
    • start is accepted (inclusive boundary)

if startBlockTimestamp != nil && block.Time().Before(*startBlockTimestamp) {
    return nil // skip pre-threshold blocks
}

Original prompt

We have a gate in firehose-core by reader-node-start-block-num and in addition to this, we would like now to also have a --reader-node-start-block-timestamp.

This would essentially at bstream level prevent block from flowing until they have their timestamp >= of the start block timestamp. Now about having inclusive or exclusive match, we want to align with Ethereum hard fork rules as the goal of this new feature is that we can do fireeth start --reader-node-start-block-timestamp=<amsterdam-hard-fork-timestamp> and such instance would only emit blocks that have been produced within the hardfork.

Created from VS Code.