doc(execution-validation): denylist.rs claims execution-level enforcement but the check is never called from EVM pre_execution #495

Summary

The module-level doc comment in crates/execution-validation/src/denylist.rs states:

Call from both mempool and execution/Revm.

In practice the is_denylisted helper is called only from the txpool validator (crates/execution-txpool/src/validator.rs:352).
It is not called from ArcEvmHandler::pre_execution, ArcEvm::before_frame_init, or anywhere else in the EVM execution path.

Reproduction (code trace)

1. crates/evm/src/handler.rs ArcEvmHandler::pre_execution calls check_blocklist (which reads NativeCoinControl) then delegates to mainnet.pre_execution. No call to is_denylisted.
2. crates/evm/src/evm.rs ArcEvm::before_frame_init performs the blocklist + EIP-7708 log path. No call to is_denylisted.
3. crates/execution-validation/src/denylist.rs is_denylisted is only imported in crates/execution-txpool/src/validator.rs.
4. ArcConsensus::validate_block_post_execution delegates to reth's standard function with no denylist check.

Impact

The docstring creates a false expectation that a denylisted address is blocked at execution time (for example, during engine API block import) as well as at the mempool level.
Under the current code, a node operator who bypasses the mempool (direct engine-API payload or a custom block proposal) could execute a transaction from or to a denylisted address.

For Arc's current trust model (Circle-operated, permissioned validator set) this may be an accepted design choice.
If so, the docstring should be corrected. If execution-level enforcement is intended, handler.rs pre_execution is the natural place to call is_denylisted for the sender and (for value-bearing calls) the recipient.

Suggested fix (documentation path)

--- a/crates/execution-validation/src/denylist.rs
+++ b/crates/execution-validation/src/denylist.rs
-//! Call from both mempool and execution/Revm.
+//! Currently called only from mempool (txpool) validation.
+//! Execution-level enforcement is not implemented; the current trust model
+//! relies on the permissioned validator set to exclude denylisted transactions
+//! from proposed blocks.

Or, if execution-level enforcement is desired, ArcEvmHandler::pre_execution would need to call is_denylisted for tx.caller() (and tx.to() for value-bearing transactions) before delegating to the mainnet handler.