chore: validate submission accounts on deserialization

[dymchenkko]

Description

submission-accounts is already validated at runtime in solver::Config::validate() (added in #4430). As suggested in this review comment, this additionally enforces the "submission accounts must be signers" invariant at config deserialization via a wrapper type, so an invalid config fails to load and the type can't be constructed in an invalid state.

Changes

• Add a SubmissionAccounts(Vec<Account>) wrapper in config/file/mod.rs whose new() constructor and custom Deserialize impl reject any address-only Account (only signers can sign EIP-7702 delegated settlements). Config loading now fails fast with a clear error.
• Use SubmissionAccounts for the submission_accounts config field; load.rs unwraps the validated list via into_inner().
• The existing runtime check in solver::Config::validate() is left in place as defense-in-depth (also guards programmatic construction); no change there.
• Add TOML deserialization tests: omitted/default → empty, signer accounts accepted, and address-only accounts rejected during deserialization.

How to test

1. cargo test -p driver --lib submission_accounts
2. Manually: add an address-only entry to submission-accounts in a driver config (e.g. submission-accounts = ["0x0000000000000000000000000000000000000002"]) and start the driver — it refuses to start with EIP-7702 submission accounts must be signers; address-only accounts cannot sign delegated settlement transactions. A private-key entry starts normally.

Related Issues

Fixes #4449

[gemini-code-assist]

Code Review

This pull request refactors the validation of EIP-7702 submission accounts by enforcing that they must be signers (and not address-only accounts) during deserialization using a new SubmissionAccounts wrapper type. Feedback on this change suggests retaining the validation check within solver::Config::validate() to ensure that programmatic constructions of the configuration remain safe and validated.

[gemini-code-assist]

While enforcing the invariant at the deserialization layer (config::file::SubmissionAccounts) is excellent for failing fast during config loading, removing the check from solver::Config::validate() leaves programmatic construction of solver::Config (e.g., in unit/integration tests or future programmatic APIs) unvalidated.

To adhere to defensive programming principles and ensure that solver::Config remains valid by construction/validation regardless of how it is instantiated, we should retain this check in validate().

        anyhow::ensure!(
            self.submission_accounts
                .iter()
                .all(|account| !matches!(account, Account::Address(_))),
            "solver '{}': EIP-7702 submission accounts must be signers; address-only accounts \\
             cannot sign delegated settlement transactions",
            self.name,
        );

[dymchenkko]

@failuresmith Thanks for the review! Applied the changes.

[failuresmith]

Longer term, I think the wrapper may belong in infra::solver, not the file-config layer. The invariant is about runtime solver behavior, so ideally solver::Config would store SubmissionAccounts instead of Vec<Account>, and both TOML loading and programmatic construction would go through the same constructor.

The current PR still improves the file-loading path and keeps validate() as a fallback, so I don’t think it has to block this change. But a domain-level wrapper would avoid maintaining the same invariant in two places.

[failuresmith]

If we want one canonical check, it should live just in the runtime/domain type, not only in file config.

The stronger design is:

// infra::solver
pub struct SubmissionAccounts(Vec<Account>);

impl SubmissionAccounts {
    pub fn new(accounts: Vec<Account>) -> anyhow::Result<Self> {
        // reject Account::Address once
    }
}

Then:

pub struct Config {
    pub submission_accounts: SubmissionAccounts,
}

Now both paths must go through the same constructor:

• TOML loading parses file::Account, converts to solver::Account, then calls solver::SubmissionAccounts::new(...).
• Programmatic construction also has to call solver::SubmissionAccounts::new(...).

---

The tradeoff is scope: moving it into solver::Config touches more call sites than #4449 likely intended.