selfdestruct-eip6780listed

# selfdestruct / EIP-6780 detection ## EIP-6780 background After Cancun (March 2024), `selfdestruct` no longer deletes the contract's code or storage *unless* called in the same transaction as the contract's deployment. It does still transfer all ether to the recipient. This changes the security model substantially: - Pre-6780: any `selfdestruct` could brick a contract → many DoS attacks. - Post-6780: `selfdestruct` outside the deploy-tx only forwards ether. Code/storage survives. ## When this applies - Any `selfdestruct` call - Contracts that assert `address(this).balance == X` (someone can force-add ether via `selfdestruct`) - `CREATE2` factories relying on redeploy at same address (now broken — code persists) - Diamonds / proxies with implementation-side selfdestruct - Pre-Cancun deployed contracts (legacy semantics still apply at runtime) ## Detection patterns ### Forced-ether DoS on balance-equality assumption (HIGH — still relevant) ```solidity require(address(this).balance == expected); // ← attacker can `selfdestruct` ether to break this ``` Track expected balance in a state variable, not via `address(this).balance`. ### CREATE2 redeploy pattern broken (HIGH) ```solidity // Pattern: deploy logic to deterministic addr, selfdestruct to "upgrade", redeploy. // ← Post-6780, code persists. Redeploy at same address fails or reverts. ``` Migrate to true proxy patterns. ### selfdestruct in deploy-tx (still has full power) (HIGH) A constructor that selfdestructs in