AccountInit

The EntryPoint is fixed per factory deployment (immutable, read from this contract's own code even under delegatecall). The account administers itself — DEFAULT_ADMIN_ROLE is granted to the account address, AND the account is its own diamond-lib Ownable owner (the DiamondCutFacet gate), so owner/EntryPoint/module changes AND upgrades flow through the validated execution path (a self-call via the ERC-7821 executor / EntryPoint), never a raw external admin. Without the initializeOwner step the blueprint's cut facet was a decoy: the owner slot stayed zero and diamondCut reverted Unauthorized() for every caller, freezing the account forever. init is safe to expose: each __*_init asserts the initializing window, so a direct call (outside a diamondCut) reverts.

SECURITY — onboarding MUST be atomic. The bare Diamond initialize that delegatecalls this is ungated, so the 7702 authorization MUST be bundled into the SAME transaction as the first UserOp (the standard 4337+7702 flow: the auth in the handleOps tx's authorization_list). Then delegation + init run in one tx and cannot be front-run. Applying the delegation in a SEPARATE, earlier tx and leaving the account uninitialized opens a window where anyone can initialize it with a hostile blueprint. Integrators who cannot guarantee atomicity should delegate to Account7702Diamond instead, whose signed onboarding closes that window on-chain. LEFTOVER STORAGE: the EOA's Solady-default Initializable and Ownable slots must be zero. A value left by an earlier Solady-based delegate makes either delegate's initializer revert, or makes initializeOwner revert AlreadyInitialized (details on Account7702Diamond).