feat(calltx): support CREATE2 receiver address list as call data source

[LouisTsai-Csie]

Summary

Let calltx take a CREATE2 receiver address list. The addresses are never enumerated: the list carries the three CREATE2 inputs: (factory, initcode hash, salt range), calltx encodes them as

callAttack(address factory, bytes32 initCodeHash, uint256 startSalt, uint256 callValue, uint256 gasBuffer)

so the contract under test derives the addresses on-chain and walks the salt upwards from startSalt. This keeps a list of tens of thousands of targets down to a few lines of config.

Configuration

New options (--targets-file, or an inline targets: block for config files and daemon mode - the two are mutually exclusive):

Option	Default	Purpose
--targets-file	-	YAML file with CREATE2 receiver patterns
--call-value	0	Wei sent by each CALL the target contract makes
--gas-buffer	50000	Gas the target contract leaves unspent before it stops looping
--salt-stride	0	Salts to advance between consecutive txs of one pattern

create2_patterns:
  - name: minimal-contracts
    factory: "{factory_address}"
    initcode: "0x60006001f3"
    start_salt: 0
    count: 20000
  - name: max-code-contracts
    factory: "{factory_address}"
    initcode_hash: "0x69bbd4b361c1909d4a86161461f44312fb9ec4112b37041b9411ad86310b6b48"
    start_salt: 0
    count: 20000

Details:

• The file uses the same YAML shape as the targets block of eoatx, so one file can be pointed at either scenario.
• factory accepts the existing {factory_address} placeholder, which expands to the CREATE2 factory of factorydeploytx.
• Exactly one of initcode, initcode_file or initcode_hash per pattern. Relative initcode_file paths resolve relative to the targets file, and start_salt uses the same uint64 big-endian bytes32 encoding as factorydeploytx.
• With several patterns, consecutive transactions round-robin over them, so one run can mix target code sizes.
• --salt-stride decides how far start_salt moves between consecutive txs of a pattern.
• Mutually exclusive with --call-data, --call-abi, --call-abi-file, --call-fn-name, --call-fn-sig and --call-args, since calltx encodes the call data itself.

Follow-up

The contract implementing callAttack: a port of the opcode = CALL, overhead_baseline = False arm of test_account_access from execution-specs - is not part of this PR and will come separately.