SyncCommitteePool runs BLS aggregation while holding the mutex #682

Follow-up from #668 (non-blocking).

SyncCommitteePool::contribution and sync_aggregate call bls::aggregate
with the std::sync::Mutex held:

• get_sync_committee_contribution (rpc/src/beacon/sync_committee.rs) does this
  on an async task, so it blocks an executor thread for the duration.
• Block production calls sync_aggregate the same way, up to four aggregations
  on the proposal path.

While the lock is held, concurrent gossip verdicts block on insert_message /
insert_contribution. Aggregation is point addition (cheap at current sizes),
so this is contention/latency, not correctness, but it sits on the proposer
critical path.

Proposed fix: clone the minimal inputs (signatures + bits) under the lock, drop
it, then aggregate. Alternatively wrap the GET handler's pool call in
spawn_blocking. Could also cache the best merged contribution per
(slot, root, subnet) on insert instead of recomputing on every read.

Related, same PR: POST /eth/v1/validator/sync_committee_subscriptions clamps
until_epoch from wall_slot(&store) instead of the head period the duties
were derived from. A fast local clock can truncate the next-period
subscription and miss sync gossip at the boundary. Should derive the clamp
from the head state.