feat(op-bridge): persist last processed block and resume via set_with_head

[temrjan]

What

Adds a key/value state table to op-bridge that records the latest block fully processed by the ExEx (number + hash). On init, the notifications stream is configured via ExExNotificationsStream::set_with_head so the ExEx resumes from the next block on restart, letting reth backfill any blocks committed while the ExEx was offline.

Updates run atomically inside a SQLite transaction so an interrupted process can never leave the state table with mismatched number/hash.

Why

Currently, on restart, op-bridge starts processing from the node's current tip and skips any blocks committed while it was offline, losing deposit/withdrawal events. With set_with_head, reth runs a backfill from the persisted head, ensuring no events are missed.

This addresses the op-bridge half of #25. A follow-up PR will handle the rollup example, which requires a heavier schema change (adding a hash column to the existing block table).

Implementation

• New state table (key/value, idempotent CREATE TABLE IF NOT EXISTS)
• read_last_processed_block / update_last_processed_block helpers (private, doc-commented)
• Persist after each committed_chain processing inside an atomic SQLite transaction
• set_with_head only called if state is present, preserving current first-run behaviour

Testing

Local baseline — all green:

• + '' + cargo build -p op-bridge + '' +
• + '' + cargo test -p op-bridge + '' + — 4 passed (was 1, added 3 unit tests: empty state, roundtrip, partial state)
• + '' + cargo clippy -p op-bridge --all-targets --all-features -- -Dwarnings + '' +
• + '' + cargo +nightly fmt --all --check + '' +
• + '' + cargo +nightly doc -p op-bridge --all-features --no-deps --document-private-items + '' + with + '' + RUSTDOCFLAGS=\"-D warnings\" + '' +

Notes

• Opened as Draft — open to feedback on the approach (state table shape, where exactly to persist, whether to also persist on revert) before finalizing.
• Rollup half of Subscribe to notifications with head in OP Bridge and Rollup examples #25 will be a follow-up PR.

Refs: #25

[temrjan]

This PR adds block persistence and resume support to the op-bridge ExEx — after a node restart, it picks up from the last processed block instead of replaying from the current tip and missing events committed while it was offline.

Based on top of main after the reth 2.0.0 bump (#58). Local baseline is green: cargo build, cargo test, cargo clippy --all-features -Dwarnings, cargo +nightly fmt --check, cargo +nightly doc --document-private-items with -D warnings.

@mattsse would appreciate your feedback on the approach — happy to adjust the state table shape, where exactly to persist, or revert-handling if you'd prefer a different design.

A follow-up PR will handle the rollup half of #25 (it also needs a small fix — db.rs queries a hash column that doesn't exist in the block schema).