fix(account): stop a hook being removed out from under its validator

[emirongrr]

Motivation

Every built-in primary validator stores a policy-hook address per account and
fails closed when that hook is not installed. Nothing connected those two facts:
_uninstallModule had no dependency check, and evictHookWithGuardians removed a
hook immediately.

That left a terminal state. With the account's only hook evicted, its validator
could no longer pass validateUserOp or validateDirectExecution;
setPolicyHook needs a scheduled self-call that only a passing validator can
reach; and guardian recovery installs validators but not hooks, so it could not
repair the account either. The account was unusable and unrecoverable.

It went unnoticed because ADR-0005's acceptance evidence for hook eviction uses
MockValidator, which declares no policy hook, so the one configuration that
makes eviction dangerous was never exercised.

Validators can now declare the dependency through ILoomPolicyBoundValidator,
and the account enforces it:

• _uninstallModule refuses to remove a hook an installed validator depends on,
  which covers the scheduled-uninstall path as well as guardian eviction.
• evictHookWithGuardians takes a replacement. When a validator depends on the
  hook a replacement is required; the account installs it, rebinds every dependent
  validator onto it, and only then removes the old hook, in that order. Eviction
  without a replacement stays available when nothing depends on the hook, so the
  escape hatch is not made harder than it needs to be.
• Initialization asserts coherence once the module set is in place, so an account
  cannot be created with a validator pointing at a hook that is not installed.

Rebinding is gated on the account reporting isEvictingHook(). Without that gate
it would be an instant, untimelocked way to re-point a validator at a permissive
hook, which setPolicyHook's configuration delay exists to prevent.

Two constraints shaped the design and are worth recording, because both rule out
the obvious alternatives:

A validator cannot check its own dependency at initialization. Module init runs
inside the account's install loop, and during a constructor or proxy deployment
the account has no code yet, so a callback into it returns nothing and reverts on
decode. The check therefore lives in the account, which can call out to a
deployed validator, and runs at the end of initialization rather than per install
-- modules arrive as a set, so a validator may legitimately name a hook that
appears later in the list.

The dependency is probed with try/catch. A validator that does not implement the
interface, or that reverts, reads as depending on nothing. That is deliberate: the
alternative hands any module a veto over hook removal, including over the guardian
escape hatch, which is the denial ADR-0005 exists to solve. The cost is that the
guard only protects modules that declare honestly, which is recorded in the
bug-class matrix.

Rejected: letting a validator fall back to "no policy hook" when its hook is
missing, which converts a liveness failure into a policy bypass; and blocking
eviction outright, which would let a malicious hook make itself unremovable.

ValidatorBranchCoverage and P256Validator each contained a test that removed a
hook to reach the validator's fail-closed branch. That state is now unreachable
through a real account, so those tests reach it through a stub account that
reports the hook absent. The branch stays covered -- it still matters for a
validator used with a non-Loom account or a future account version -- without
requiring the account to permit an incoherent state.

Scope

Included

• The change, its tests, and the documentation that describes the changed behaviour.

Not included

• Unrelated refactors. Each audit finding is on its own branch.

Security impact

Authority and availability. A hook could be removed out from under the validator that depends on it.

Verification

• forge test, npm run test:mutation:critical.

Residual risks

Three pre-existing tests reach the fail-closed branch through a stub account rather than by uninstalling a hook; the stub is new, the assertions are unchanged.

Checklist

• This pull request has one reviewable purpose
• Tests cover the changed behavior and important failure paths
• npm run verify passes (full program not run locally; forge test and the finding-specific gates are green)
• Gas and bytecode changes are measured or not applicable
• Security assumptions and residual risks are explicit
• Branch history is clean

[emirongrr]

Follow-up commit 051bea4e: docs/design/execution.md still asserted that this function "can only uninstall a hook - it cannot install one", which the replacement path makes false. Corrected, and the residual is now stated in both the design document and decision 0005 rather than left implicit — the guardian threshold chooses the contract that gates direct execution, which is bounded by recovery already being able to replace every validator, but differs from it in being immediate rather than visible for three days.

[emirongrr]

Held: this cannot merge as it stands. With this branch LoomAccount runtime reaches 25,146 bytes against the 24,576 EIP-170 limit — 570 over, where main currently sits 910 under. forge build --sizes exits non-zero and both tools/ci/verify.mjs and the ci workflow run it, so CI fails correctly. Measured, not estimated: removing evictHookWithGuardians alone takes the runtime to 24,015 (+561 margin), so that one function is 1,131 bytes.

Moving the logic to a library only helps if it is a deployed, link-time-bound library with public functions. All three existing libraries here (ExecutionLib, ValidatorSetLib, GuardianVerificationLib) are internal-only and therefore inlined, so they save no bytecode; there is no library linking in foundry.toml and no library deployment in the scripts. Introducing one would add a deployment artifact, a manifest entry, and a component the account delegatecalls into — a new pattern for this repository and a new line in the trusted computing base.

Separately, one real defect was found and fixed while merging: the coherence check added here reverted recoverConfiguration once P256RecoveryValidator (from #299) inherited policyHookFor. Recovery is now exempt, bounded by a test asserting the ordinary path still refuses the same validator, with the reasoning in decision 0005. 391 tests pass, 13/13 guard mutants killed.

The remaining audit PRs are being merged ahead of this one.