Unify lock usage; prefer actor ownership over shared locks

Summary

Lock usage is split with no documented rule: std::sync::{Mutex,RwLock} in 41 files, tokio::sync in 22 (parking_lot is not a dependency — the backlog can drop that option). 52 call sites deal with poison (PoisonError::into_inner / expect("... poisoned")).

Several locks guard data with a single logical owner, where a channel/actor removes the lock entirely:

• expired_rx: Mutex<Option<mpsc::Receiver<Duty>>> — a mutex wrapping a channel receiver just to make it &self-takeable, the textbook symptom.
• instances: Arc<Mutex<HashMap<Duty, Arc<InstanceIo<Msg>>>>> — per-duty registry with one owner.
• parsigdb's Arc<tokio::sync::Mutex<MemDBInner>> — already half-actor (it has an mpsc trim loop).
• dkg/sync/client.rs#L40-L42 mixes a std::sync::RwLock with watch::Senders in the same struct; dkg's Mutex + Notify pairs are hand-rolled actors.
• P2PContext::peer_store returns RwLockReadGuard/WriteGuard from public methods, leaking guards across the API boundary.
• SUPPORTED_NETWORKS: LazyLock<RwLock<Vec<Network>>> — a mutable process-global registry.

Proposed change

This is a design task first: pick a general rule (the standard one works: std::sync for short, non-await-crossing critical sections; tokio::sync when a guard is held across .await; actor + channels when data has one logical owner), document it and enforce it. Later, convert the listed actor candidates. Finally:

• Stop returning guards from P2PContext
• Make SUPPORTED_NETWORKS immutable-after-init or explicitly injected.

Acceptance

A written rule in the style docs, and the flagged sites either converted or annotated with why the lock is the right shape.

Start by reading the listed lock sites in crates/consensus/src/qbft/component.rs, crates/core/src/parsigdb/memory.rs, crates/dkg/src/sync/client.rs, crates/p2p/src/p2p_context.rs, and crates/eth2util/src/network.rs, then review the existing style documentation. Done means the lock-ownership rule is documented and the flagged sites are converted or annotated with why their current lock shape is appropriate.