refactor: move salt bucket capacity lookup into revm::Database trait

[WonderLawrence]

Summary

This PR refactors how SALT bucket capacity is queried during EVM execution for v1.4.1, removing the SaltEnv abstraction and integrating capacity lookup directly into the revm::Database trait via a new salt_bucket_capacity(address, Option<U256>) -> (usize, u64) method.

Problem

Previously, bucket capacity was provided through ExternalEnvTypes::SaltEnv — an external environment trait injected via ExternalEnvFactory. This required the factory to accept a block: BlockNumber parameter to return historically-correct capacity values. The design was overly complex and coupled gas calculation to an external oracle abstraction rather than the database layer.

Changes

• Remove SaltEnv trait and ExternalEnvs::salt_env field: All SALT bucket capacity queries now go through db.salt_bucket_capacity(address, key) on the revm::Database trait (added in the upstream megaeth-labs/revm-database-interface fork)
• DynamicGasCost is no longer generic: DynamicGasCost<SaltEnvImpl> → DynamicGasCost; gas functions (sstore_set_gas, new_account_gas, create_contract_gas) now take db: &DB directly
• ExternalEnvFactory::external_envs drops the block parameter: Block context for historical capacity resolution is now handled at the database level by the caller (e.g. StateProviderDatabase wrapping a HistoricalStateProviderRef)
• TestDatabaseWrapper introduced: Replaces TestExternalEnvs::with_bucket_capacity for test setups; wraps any revm::Database and provides configurable per-bucket capacity overrides

Motivation

The revm::Database is already the single source of truth for all state during execution. Routing capacity queries through it allows historical replay correctness to be handled entirely at the storage layer (see megaeth-labs/mega-reth#1489), without requiring the EVM execution layer to know about block numbers or provider types.