Is Lodestar’s 30-Minute Peer Ban Cooldown Intentional?

### Describe the bug

## Background: What is "ban cool down before decay"?

Lodestar scores each peer in `[−100, 100]`. When a peer's score drops to −50 (the ban threshold), it is disconnected and blocked.
The score is then frozen for a fixed window (`COOL_DOWN_BEFORE_DECAY_MS`) before decay resumes.
This window is the minimum time a banned peer stays out.

## Divergence from Lighthouse

The ban cool-down is shorter in Lodestar than in Lighthouse. A banned peer can
start recovering its score after 30 minutes in Lodestar. The same process takes
12 hours in Lighthouse.

**Lodestar** (`packages/beacon-node/src/network/peers/score/constants.ts`):

```ts
/** The number of milliseconds we ban a peer for before their score begins to decay */
export const COOL_DOWN_BEFORE_DECAY_MS = 30 * 60 * 1000; // 30 minutes
```

**Lighthouse** (`beacon_node/lighthouse_network/src/peer_manager/peerdb/score.rs`):

```rust
/// The number of seconds we ban a peer for before their score begins to decay.
const BANNED_BEFORE_DECAY: Duration = Duration::from_secs(12 * 3600); // 12 hours
```

This is the only difference we found in the main peer-scoring parameters. The
disconnect threshold, ban threshold, score floor, score range, score half-life,
and gossipsub bridge weight are the same.

| Constant | Lighthouse | Lodestar |
|---|---|---|
| Disconnect threshold | −20 | −20 |
| Ban threshold | −50 | −50 |
| Score-only ban floor | −60 | −60 |
| Score range | [−100, 100] | [−100, 100] |
| Score half-life | 600 s | 600 s |
| **Ban cool-down before decay** | **12 h** | **30 min** |

Verified at `lodestar@98e4089` (`constants.ts:22`) and `lighthouse@e3ee7feb`
(`score.rs:34`).

## Potential Impact

A peer banned for misbehavior on Lighthouse is free to reconnect to a Lodestar node after
just 30 minutes and repeat the same behavior. Across a heterogeneous network, the effective exclusion time of a
misbehaving peer is set by its *most lenient* victim. For Lodestar operators
this shortens the recycle time of peers that gossip-level scoring has already
judged harmful.

Whether this is an intentional policy choice (e.g., suited for smaller peer
pools) or an unnoticed divergence from the port is what we'd like to clarify.

### Concrete Example of Harm

An attacker controls a malicious peer that is programmed to flood the network with invalid gossip messages (e.g., invalid attestations or unverifiable blocks) in order to waste other nodes' CPU and bandwidth.
- Against a Lighthouse node (12 hours cooldown):
The malicious peer's score drops to −50 and it is banned. Its score remains frozen for 12 hours. During those 12 hours, the attacker cannot reconnect to that Lighthouse node and must find other targets. If enough Lighthouse nodes ban it, the attacker is effectively shut out of a large portion of the network for half a day, significantly disrupting its campaign.
- Against a Lodestar node (30 minutes cooldown):
The same malicious peer is banned after its score hits −50. However, its score freezes for only 30 minutes. After that short window, the score starts recovering, and the peer is allowed to reconnect. The attacker simply waits 30 minutes, reconnects to the same Lodestar node, and resumes sending invalid messages.
### The real-world consequence:
An attacker can repeatedly target Lodestar nodes with the same abusive behavior multiple times per day (e.g., up to 48 times in 24 hours) with almost no lasting penalty. In contrast, against Lighthouse nodes, the same attacker can only strike once per 12 hours before being locked out. Because Lodestar nodes are the "most lenient" victims, the attacker's overall operational cost drops dramatically — they no longer need to rotate through many distinct IP addresses or nodes; they can recycle the same few malicious peers endlessly against Lodestar operators, degrading those nodes' performance continuously while spending minimal resources.

### Expected behavior

The peer-ban cool-down should be an explicit, documented policy. If Lodestar
intends to preserve Lighthouse's peer-scoring semantics, the default should
match Lighthouse's 12-hour cool-down; otherwise, the 30-minute divergence
should be documented and preferably configurable.

### Steps to reproduce

_No response_

### Additional context

_No response_

### Operating system

Linux

### Lodestar version or commit hash

v1.39.0

Start with packages/beacon-node/src/network/peers/score/constants.ts at COOL_DOWN_BEFORE_DECAY_MS, then compare the corresponding BANNED_BEFORE_DECAY constant in Lighthouse's beacon_node/lighthouse_network/src/peer_manager/peerdb/score.rs. Confirm whether the 30-minute value is intentional; done means the policy is explicitly documented or the default is aligned with the intended peer-scoring behavior and any configurability is defined.

Written by the indexing model from the issue text.