Fix false-positive assertion violation (SWC-110) at PC 0 for contracts without assert (#1911)

[jose-compu]

Problem

myth analyze -c <bytecode> reports a spurious SWC-110 (Assertion Violation) on Solidity contracts that contain no assert() statements. The false positive appears at PC address 0 with function name fallback.

This occurs because the -c flag treats input as creation bytecode by default. When runtime bytecode is fed this way, the symbolic executor runs it as a constructor, and the RETURN instruction deploys arbitrary memory content as the "runtime code." If the first byte of that garbage happens to map to INVALID (or any unrecognized opcode), the Exceptions module flags it as an assertion violation — even though no assert() exists in the original contract.

Reported in #1911 with a reproducible example compiled via solc --optimize --via-ir --bin-runtime with heavy Yul optimizations.

Fix

Added a guard in Exceptions._analyze_state() that skips INVALID opcodes at address 0. No legitimately compiled Solidity contract starts with an assertion; the first instructions are always the free-memory-pointer setup (PUSH1 0x80 PUSH1 0x40 MSTORE). An INVALID at PC 0 is reliably an artifact of non-contract bytecode being executed.

Testing

• Added regression test test_no_assert_false_positive_at_pc0 using the exact bytecode from the issue report.
• All 14 existing analysis tests pass, including the exceptions_0.8.0.sol.o tests that verify legitimate assertion violations (2 issues) are still correctly detected.

[CLAassistant]

All committers have signed the CLA.

[jose-compu]

please review @yrashk @lazzarello @rocky if you can.