fix(verify): do not panic when constructor args are longer than the bytecode

[mkzung]

Motivation

forge verify-bytecode panics instead of reporting a mismatch when --constructor-args is longer than the code at the address.

is_partial_match strips the args off the end of both buffers without checking either is that long:

bytecode = &bytecode[..bytecode.len() - constructor_args.len()];
local_bytecode = &local_bytecode[..local_bytecode.len() - constructor_args.len()];

Both operands are usize, and the args come from the command line while the on-chain side is whatever the address holds, so the subtraction underflows:

thread '...' panicked at crates/verify/src/utils.rs:194:28:
attempt to subtract with overflow

mablr raised this on #16054.

Solution

checked_sub on both, returning false when either is too short. A pair like that is a mismatch, and the caller already treats false as one.

The test asserts None from match_bytecodes with four bytes of local code, two on chain and 32 bytes of args. It panics on master and passes with the change, and reverting only the checked_sub with the test kept brings the panic back. forge-verify goes from 56 tests to 57, all passing.

Not addressed here, because it is a behavioural call rather than a crash: the stripped suffix is still never compared with the args that were supplied, so two different sets of the same length read alike. That is the wider half of mablr's point. Happy to follow it up separately if you want the matcher to check the suffix.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[github-actions]

✅ Changelog found

The deterministic check will validate the changed entry.