fix(sync): forward catch-up so behind/new nodes can sync (deep-fork ④)

[lai3d]

Fix ④ from the testnet recovery plan — the last code fix before the reset.

Problem

A node that fell behind could never catch up. handle_block walked the peer's chain backward by parent hash into a bounded pending buffer (MAX_PENDING_BLOCKS = 1000) that dropped blocks as fast as it queued them — so it imported nothing and re-requested forever. (This is the deep-fork sync defect, and the source of the ~20k-writes/s log flood T1 found.)

Fix

The correct forward range-sync path already existed but was dead code (sync_with_peer / sync_blocks_from_peer, "Will be used when initial sync is implemented"), and the wire protocol already serves GetBlockByNumber / GetBlockRange. This wires it up:

• run_catch_up_loop — every 5s, if we're more than CATCH_UP_LAG_THRESHOLD (2) blocks behind the highest known peer, range-sync the gap forward and import blocks in order. In-order import has no missing-parent step, so there's no pending-buffer overflow — it catches up from any depth, including a fresh node from genesis. Sequential (each tick awaits the full sync) so catch-ups never overlap; spawned in main.rs next to the message/event handlers.
• sync_with_peer un-dead-coded (verifies the peer's genesis hash before syncing).
• The gossip backward-walk stays for small reorg gaps only.

Tests

• should_catch_up_threshold — fires only when > 2 behind (never level / 1–2 behind, avoiding thrash), and fires for a genesis catch-up. qfc-node 21 unit tests pass; fmt + clippy clean.
• End-to-end forward sync is exercised by the testnet reset (a node catching up on the fresh chain).

Context

With consensus convergence (#126) nodes no longer fork; this lets a lagging or newly-joined node rejoin and catch up without re-forking — making the planned testnet reset durable. After this lands → promote to staging → reset (Strategy A).

🤖 Generated with Claude Code