Fix warp-synced node getting stuck on a reverted fork

[dimartiro]

Description

Closes #10398.

Right after warp sync, a node can import a few blocks that turn out to belong to a fork which is later reverted. It then ends up with its best block on a dead fork a few blocks above the last finalized block, and every attempt to import the canonical successor fails with block has an unknown parent — the node never recovers on its own (only wiping the database and re-warp-syncing helps).

Root cause

After importing the (later reverted) fork, the affected peers' common_number is inflated up to our forked best, which sits above the finalized block. Both ancestor-search recovery paths are gated off for this case:

• on_validated_block_announce skips ancestor search during major sync (intentional, to avoid pulling peers out of the download pool — covered by no_ancestry_search_during_major_sync).
• the ancestor search in block_requests only triggers when best_queued - common_number > MAX_BLOCKS_TO_LOOK_BACKWARDS (1024) and common_number < finalized — a short fork of a few blocks meets neither.

On the UnknownParent import error, on_blocks_processed calls restart(), but during major sync the import queue is usually larger than MAJOR_SYNC_BLOCKS, so add_peer_inner re-adds peers assuming the common block is our (forked) best instead of starting an ancestor search. The node then loops: request the canonical successor → UnknownParent → restart → assume common = fork tip → repeat, and ends up idle on the wrong best block.

Fix

On an UnknownParent import error, after restart(), re-anchor every peer's common_number down to the finalized block — the highest block we are certain is shared with honest peers. This makes the next round of block requests re-download the canonical chain from the actual fork point, so the node recovers without operator intervention.