feat(execution): return result of error if panic when execution

[AshinGau]

Summary

This PR establishes a typed error path for Gravity's pipe execution instead of panicking, unwrapping runtime failures, or dropping the results of spawned block tasks.

The main changes are:

• add PipeBlockError with block ID, block number, epoch, and execution stage context;
• preserve concrete error types such as ProviderError, BlockExecutionError, and ChannelError so callers can classify failures without string parsing or downcasting;
• make PipeExecService supervise block tasks through a JoinSet, observe returned errors and task panics, and shut down all pipe barriers and channels consistently after the first fatal failure;
• propagate provider, state-view, migration, system-transaction, transaction-filter, block-executor, state-root, verification, and canonicalization errors through one Result spine;
• return canonicalization ProviderResult from the engine tree to the pipe, while treating a dropped oneshot response receiver as best-effort delivery cancellation;
• distinguish channel timeout, closure, duplicate waiter/notification, and poisoned state;
• keep failed-block diagnostic dumps best-effort so dump I/O errors cannot hide the original executor error;
• propagate transaction-filter database errors instead of misclassifying them as invalid transactions.

Motivation

The pipe previously spawned one task per block and discarded each task handle. Several runtime error paths then used unwrap, expect, or panic!. For example, an executor error caused the node to panic after attempting to dump the block, while a dump failure could panic first and hide the actual execution error.

The EIP-7702 nonce-side-effect issue demonstrated why this boundary matters: a filter/executor mismatch can cause the executor to return an error for an ordered block. Known recoverable validation cases should be filtered and represented by the existing skipped receipt, but provider or executor failures must retain their concrete cause and reach a single owner that can stop the local pipe safely.

Error semantics

Condition	Behavior
Existing allowlisted invalid transaction	Keep the existing skipped receipt and continue the block
EVM Revert or Halt result	Keep normal receipt semantics
Provider, state-root, migration, system-transaction, or executor error	Return a typed block error and stop the local pipe
Verified block hash mismatch or pipe ordering violation	Return an explicit typed error and stop the local pipe
Execution-result owner closes its channel	Treat as cancellation and shut down cleanly
Canonical event/ack channel disappears	Treat as fatal because the canonical operation result is unknown
Response receiver is already dropped	Ignore the best-effort delivery failure; do not convert it into a block failure

"Fatal" here means that this node's pipe cannot safely continue from potentially partial state. It does not imply that the block is invalid or that the error necessarily affects the whole network.

Scope

This PR intentionally does not:

• broaden the set of transaction errors that may be skipped;
• attempt to continue execution after an unknown executor failure;
• add in-process rollback, block retry, rejection, or re-proposal semantics;
• replace every invariant unwrap or expect in gravity-reth;
• change the coordinator-facing PipeExecLayerApi workflow.

A consensus-layer interface for reporting and recovering from block execution failures remains a separate design problem.

Testing

• cargo test -p reth-pipe-exec-layer-ext-v2 --lib — 64 passed
• cargo test -p reth-engine-tree --lib --no-run
• cargo check -p reth-pipe-exec-layer-ext-v2 -p gravity-storage -p reth-pipe-exec-layer-event-bus -p reth-engine-tree
• cargo fmt --all
• git diff --check