Node restarted from genesis proposes on top of genesis before syncing #785

Summary

A lean node that restarts from genesis (no checkpoint sync, ~1000 slots behind the network) builds and publishes a block on top of genesis about 1 s after start, before it has synced. It reorgs away as soon as sync catches up, but its attestations to the genesis head make peers reject them.

Evidence

Local 3-node lean devnet (built from lean-quickstart genesis), node lean2 wiped and restarted while the network was at slot ~1000. Binary: branch spawned-v0.7 (#783); that branch does not change block production or fork choice, so this should reproduce on main (not yet confirmed there).

18:30:59.556 INFO ethlambda: No checkpoint sync URL provided, initializing from genesis state
18:30:59.593 INFO ethlambda: Node initialized
18:31:00.605 INFO ethlambda_blockchain: Published block slot=1001 validator_id=2
18:31:00.605 INFO ethlambda_p2p::gossipsub::handler: Published block to gossipsub slot=1001 proposer=2 block_root=71497f23 parent_root=633e24a2 attestation_count=0
18:31:00.629 INFO ethlambda_blockchain::store: Fork choice reorg detected old_head=0x71497f23… new_head=0xf9cbe592…
18:31:00.629 INFO ethlambda_blockchain::import_timing: Block import timing slot=1 … source="sync"

parent_root=633e24a2 is the genesis block. Peers then logged:

WARN ethlambda_blockchain: Failed to process gossiped attestation err=Head checkpoint 0x633e24a2… at slot 0 does not descend from finalized block 0x9e6ceb4a…

Expected

A node that is far behind the network's head should not propose (or attest to its stale head) until it is synced, or at least until its head is within some distance of the wall-clock slot.