feat(pin sigcheck): pinning signature validation implementation

[zeroknots]

TheCompact’s ValidityLib is using Solady's SignatureCheckerLib.
In the Solady version that TheCompact is using, isValidSignatureNowCalldata() checks the signature length to decide whether to perform ecrecover (then ERC1271 fallback) based on the signature length (over 65 bytes it uses ERC1271)..
However, In the current Solady version, isValidSignatureNowCalldata() will EXTCODESIZE check, if EXTCODESIZE is non-zero, it goes straight to ERC1271.
Note: with the currently pinned Solady version, there is no security risk!

Considering EIP7702 is around the cordner, this opens up some attack vectors specifically for credible commitments, should the newer Solady version be used.

According to EIP7702 Spec:

“The delegation designation uses the banned opcode 0xef from EIP-3541 to designate the code has a special purpose. This designator requires all code executing operations to follow the address pointer to get the account's executable code, and requires all other code reading operations to act only on the delegation designator (0xef0100 || address). The following reading instructions are impacted: EXTCODESIZE, EXTCODECOPY, EXTCODEHASH, and the following executing instructions are impacted: CALL, CALLCODE, STATICCALL, DELEGATECALL, as well as transactions with destination targeting the code with delegation designation.
For example, EXTCODESIZE would return 23 (the size of 0xef0100 || address), EXTCODEHASH would return keccak256(0xef0100 || address), and CALL would load the code from address and execute it in the context of authority.”

Attack Scenario:

• User locks resources into TheCompact
• User uses EIP7702 to upgrade EOA to a modular smart account, with a validator module. For example an ERC7579 passkey validator module
• User Signs a Compact to allow a solver to take out the funds, with a signature that would be valid with the passkey validator module
• When solver wants to send the claim, the user frontruns the solver's claim, by deactivating the validator module, or changing EIP7702 account implementation.

Remediation:

• Allocators / Solvers can only trust ecrecover-able signatures, if the account is an EOA (EIP-7702).
• I recommend adding the bytecode of the isValidSignatureNowCalldata() to TheCompact repository, to prevent future dependency upgrades to introduce the attack scenario mentioned above