Prefer fixed invariant sender pool

[decofe]

Summary

• change invariant fuzzing to prefer a fixed default sender pool modeled after Echidna
• include Foundry's default deployer/caller in that pool
• keep a rare random/dictionary sender fallback for broad exploration
• preserve targetSenders()/excludeSenders() behavior

Prompted by: @0xalpharush

Tests

• cargo test -p foundry-evm-fuzz default_sender_pool -- --nocapture
• cargo test -p foundry-evm-fuzz strategies::invariants -- --nocapture

[0xalpharush]

derek bench invariant

[github-actions]

cc @0xalpharush

bench (invariant) event published. Results will be reported separately. View publisher run

Config: subcommand: invariant, PR SHA: a243d366d0f4, compare-ref: master, timeout: 3600s, workers: default, benchmark-type: property

[stevencartavia]

Proposal: split the sender weighting from --invariant-dictionary-weight. After this change, when targetSenders is empty the sender comes 99% from the fixed pool and only 1% from the random/dictionary strategy, so the knob barely affects which address sends the tx anymore.

To check, I counted how many of 400 sender draws were not one of the three new fixed-pool addresses. On master, raising the dictionary weight from 0 to 100 changes that count from 400 down to ~203 — so the knob clearly drives sender selection. On this PR it stays at ~2–3 regardless of the weight.

Maybe we can add a dedicated weight for the fixed-pool-vs-random/dictionary split, and leave dictionary_weight to govern calldata plus the fallback branch. That keeps the new Echidna-style default while still letting users dial sender randomness back up, and avoids making the existing help text (invariant calldata/senders) misleading.

[grandizzy]

derek bench invariant timeout=7200

[github-actions]

cc @grandizzy

bench (invariant) event published. Results will be reported separately. View publisher run

Config: subcommand: invariant, PR SHA: a4db2aa9aef6, compare-ref: master, timeout: 7200s, workers: default, benchmark-type: property