fix(blocksync): prevent maxPeerHeight poisoning by peers with inflated base

[fridrik01]

Each peer advertises a (base, height) range in StatusResponse declaring the contiguous blocks it can serve. base is the oldest block it still has (moves up if the peer prunes), height is the newest. A malicious peer can advertise something like base=100_000_000, height=100_000_100 to poison maxPeerHeight with a value no peer can serve, which can deadlock blocksync. The attack window opens on any validator restart, not just on genesis sync.

This is a minimal fix while we wait for the upstream patch.

Changes:

• updateMaxPeerHeight now excludes peers whose base > pool.height from the maxPeerHeight computation.

Tests:

• TestBlockPoolIgnoresPeersWithInflatedBase: verifies a peer with base > pool.height does not raise maxPeerHeight.
• TestBlockPoolTimeout: forced uniform base=start so all peers contribute to maxPeerHeight. The staggered bases from makePeers combined with the new gating would otherwise starve the request pipeline since this test never advances pool.height.