EVM status-check poll cadence is not env-configurable

Describe the feature

Stellar's status poll cadence became env-configurable in #846. The EVM equivalent is still compiled in:

• EVM_STATUS_CHECK_INITIAL_DELAY_SECONDS = 8 — src/constants/evm_transaction.rs
• STATUS_EVM_BACKOFF = 8000ms initial / 12000ms max — src/queues/retry_config.rs

So the first status check lands 8s after submission no matter how fast the chain is, and a missed first check waits another 8–12s. retry_config.rs asserts the ladder directly:

status_check_retry_delay_secs(Some(NetworkType::Evm), 0) == 8
status_check_retry_delay_secs(Some(NetworkType::Evm), 1) == 12

On a chain with sub-second blocks and required_confirmations: 1, that 8s is a floor on how quickly a transaction can be reported confirmed — it has been on-chain for ~7s by the time the first check runs. A client polling the status endpoint sees a p50 that tracks the constant rather than the chain, and there's no way to tune it without forking.

Additional context

Happy to open a PR mirroring #846 for EVM — same three knobs, same 0-60 / 500-60000 validation, defaults unchanged so existing deployments are unaffected.

Start by comparing the Stellar implementation in #846 with src/constants/evm_transaction.rs and src/queues/retry_config.rs. Trace the existing EVM delay constants and retry assertions, then mirror the three configurable knobs with the stated 0-60 and 500-60000 validation. Done means the defaults remain unchanged and the EVM retry-delay tests cover the configurable values.