Make `ValidatorCache` in `BeaconNodeClient` immutable

[emlautarom1-agent]

Summary

The ValidatorCache stored in BeaconNodeClient is currently modeled as mutable, shared, optional state. It should probably be set once during construction instead of supporting later modification (and the "unset" state).

This is captured by an existing TODO in the code:

https://github.com/NethermindEth/pluto/blob/main/crates/eth2api/src/beacon_node.rs

pub struct BeaconNodeClient {
    api: EthBeaconNodeApiClient,
    // TODO: Find the concrete usages of the `validator_cache` and consider if we can make it
    // immutable, that is, set it once at construction and not have to deal with the possibility of
    // it being unset later.
    validator_cache: Arc<RwLock<Option<ValidatorCache>>>,
}

Current behavior

• The cache is held as Arc<RwLock<Option<ValidatorCache>>>.
• It is initialized to None in BeaconNodeClient::new.
• It is populated later via set_validator_cache, meaning every read has to handle the "not yet set" case (BeaconNodeClientError::NoActiveValidatorCache).

This optionality leaks into callers. For example, in the scheduler (crates/core/src/scheduler.rs), reading the cache forces an expect, with a TODO noting it should always be available:

let valcache = self
    .client
    .validator_cache()
    .await
    // TODO: [`pluto_eth2api::valcache::ValidatorCache`] should always be available.
    .expect("validator cache is available");

Proposed change

• Audit the concrete usages of validator_cache / set_validator_cache.
• If the cache is always known at construction time, make it immutable: pass it into BeaconNodeClient::new (or a dedicated constructor) and store it as a plain ValidatorCache field.
• This removes:
  • the Option/RwLock wrapping,
  • the set_validator_cache setter,
  • the NoActiveValidatorCache error variant,
  • and the downstream expect("validator cache is available") in the scheduler.

Open questions

• Are there any flows where BeaconNodeClient legitimately needs to exist before the validator cache is known? If so, immutability at construction may not be feasible and we should document why the optional state is required instead.

[emlautarom1-agent]

Update: "no cache" error path removed; mutability concern remains

A follow-up commit (Fix missing ValidatorCache issues) makes BeaconNodeClient always hold a valid ValidatorCache, defaulting to a new empty cache at construction:

pub fn new(api: EthBeaconNodeApiClient) -> Self {
    Self {
        api: api.clone(),
        validator_cache: Arc::new(RwLock::new(ValidatorCache::new(api, Vec::new()))),
    }
}

What this resolves

• validator_cache changed from Arc<RwLock<Option<ValidatorCache>>> → Arc<RwLock<ValidatorCache>>; there is no longer an "unset" state.
• The BeaconNodeClientError::NoActiveValidatorCache variant was removed.
• validator_cache() no longer returns Result — it just returns a ValidatorCache.
• The downstream expect("validator cache is available") in crates/core/src/scheduler.rs is gone:

let valcache = self.client.validator_cache().await;

What still stands

The core concern of this issue — the cache being mutable rather than set once at construction — is unchanged:

• It is still wrapped in Arc<RwLock<...>>.
• set_validator_cache still allows replacing the cache after construction.
• The TODO in crates/eth2api/src/beacon_node.rs about making it immutable remains.

So we've traded the "missing cache" failure mode for a default empty cache, but the open question stands: can the real cache be supplied at construction time so the RwLock and the setter can be removed entirely?