feat: Add 7702 Semi-Modular Account Support

[Zer0dot]

Motivation

With EIP-7702 around the corner, developers would benefit from having a simple example of a Semi-Modular Account with a fallback signer that defaults to the address of the account itself.

Solution

Implement a variant of the Semi-Modular Account which includes the address of the account itself as the fallback signer rather than reading from bytecode as is done in the standard Semi-Modular Account.

This PR also affects the base Semi-Modular Account contract by making the account ID and unchecked fallback signer getter functions virtual as they must be overriden in the 7702 variant.

[octane-security-app]

Summary by Octane

New Contracts

• SemiModularAccount7702.sol: The smart contract prevents upgrades and manages fallback signers for a semi-modular account with 7702 support.

Updated Contracts

• ReferenceModularAccount.sol: Added a virtual keyword to the upgradeToAndCall function, allowing further overrides.
• SemiModularAccount.sol: Made functions accountId and _retrieveFallbackSignerUnchecked virtual, allowing further overrides.

---

🔗 Commit Hash: f9215cd

[octane-security-app]

Overview

Vulnerabilities found:	1
Severity breakdown:	1 Medium

Detailed findings

src/account/ReferenceModularAccount.sol

• Review potential Denial of Service issue that is exposed in the upgradeToAndCall function

---

🔗 Commit Hash: f9215cd
🛡️ Octane Dashboard: All vulnerabilities

[howydev]

LGTM

1 small security callout is that the upgradeToAndCall path still exists to perform an arbitrary call on the account, but this should be protected in the default cases of selector validation since that's an allowlist model

[adamegyed]

+1 to @howydev 's point, we should prevent calling upgradeToAndCall as a footgun-prevention mechanism