feat(supervisor/core): handle invalidate blocks

[dhyaniarun1993]

Closes #2435
Close #2436

[codecov]

Codecov Report

❌ Patch coverage is 94.18605% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.5%. Comparing base (b3833f9) to head (c1dc1a9).
⚠️ Report is 7 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/supervisor/core/src/chain_processor/task.rs	94.0%	20 Missing ⚠️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull Request Overview

This PR implements invalidate block handling functionality in the supervisor core component. The primary purpose is to add support for handling block invalidation events and subsequent block replacement operations in the chain processor.

Key Changes:

• Added InvalidateBlock event type to the chain event system
• Implemented invalidate block and block replacement handling logic with state management
• Changed primitive types from U64 to u64 for block numbers and timestamps

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
crates/supervisor/types/src/types.rs	Changed BlockSeal fields from U64 to native u64 type
crates/supervisor/core/src/event/chain.rs	Added new InvalidateBlock variant to ChainEvent enum
crates/supervisor/core/src/chain_processor/task.rs	Implemented core invalidate block handling logic and block replacement processing
crates/supervisor/core/src/chain_processor/chain.rs	Updated trait bounds to use consolidated storage traits

Comments suppressed due to low confidence (1)

[emhane]

smol comments on log level, asides that lgtm

we want log levels to be used like this:
INFO Handling reorg for chain sequence start_block=X ...
DEBUG Replacing blocks old=X new=Y ...
TRACE Entering a specific method args=X, e.g. handle_invalidate_block ...
INFO Reorg successful new_head_hash=X.

does that make sense?

recap on how to think about log levels:
we want to use log filters by target in the most helpful way, e.g. we are isolating a bug in target chain_processor which is triggered in the interaction with target supervisor_service, then we use the log filter RUST_LOG=supervisor_service=debug,chain_processor=trace in order to observe chain processor with more granularity and supervisor with less granularity at the same time. that's why it's important that debug log levels (and info log levels) aren't too verbose, and that we make use of trace log level for that, because we have to take into account observing several components at the same time with different granularity.