Alt epoch record vote counting doesn't track unique voters

[grantkee]

• Description: When a vote has a different epoch_hash than expected (alternative epoch record), the code increments a simple counter per hash. It does not track which public keys have already voted. A single validator could send the same alternative vote repeatedly, inflating the count to reach quorum and triggering the break at line 117-124, causing the node to abandon its own epoch record aggregation.
• Impact: A malicious committee member could disrupt epoch certification by spamming alternative votes. The node would log "Reached quorum on epoch record X instead of Y" and exit the vote collection loop. The recovery path (lines 196-231) attempts to download the correct epoch record from peers, so this doesn't cause permanent damage, but creates unnecessary disruption and delays epoch transitions.
• Analysis: Gossipsub deduplicates by message ID within a cache window (~5 seconds), but a validator could resend after the cache expires or via different peers. The committee_keys.remove(&source) deduplication at line 98 only applies to matching-hash votes, not alt-hash votes. The counter at line 116 is a plain usize that increments for every alt vote received, regardless of whether the same validator already voted.