fix(analysis): distinguish Foundry handler assertions

[figtracer]

Summary

• identify current Foundry handler assertion failures by target address and selector
• preserve the existing invariant and legacy-record fallbacks
• cover two selectors on the same handler when the log ends before another metrics pulse

Root cause

Current Foundry JSON emits handler assertions with failure_type: handler_assertion, a target address, and a function selector. The analyzer ignored the selector and used only the target, collapsing distinct assertion sites into one bug. A later metrics pulse could restore the total with anonymous synthetic bugs, so the reported count depended on whether that pulse arrived before the run ended.

Validation

• python -m unittest analysis.tests.test_analyze_foundry_parser -v (13 tests)
• python -m unittest discover -s analysis/tests -v (128 tests)
• replayed a captured Aave Foundry log; the analyzer now reports both handler selectors and both invariant failures immediately

[mablr]

Makes sense, have you tested it locally on PRs ? foundry-rs/foundry#15818 or foundry-rs/foundry#16065 ?

[figtracer]

yes, it makes bug discovery time more accurate since it doesn't bundle same target findings @mablr

doesn't explain the whole thing but can help on edge cases where it might depend on the pulse

[mablr]

Okay LGTM

cc @0xalpharush @grandizzy

[grandizzy]

lgtm, ty