fix: rotate stalled active gossip sync peers

[jjyr]

Summary

• track consecutive no-progress results during active gossip sync
• require validated cursors to advance monotonically before updating the local cursor or resetting the stall budget
• count pending dependency results, non-advancing validated cursors, and request timeouts through one bounded abort path
• add end-to-end regression coverage for missing dependencies, duplicate-cursor bypasses, and silent peers

Why

An active sync peer can keep a limited sync slot indefinitely by returning messages whose dependencies are unavailable, replaying already-known messages that do not advance the cursor, or never answering requests. The receiver previously retried the same peer without a bounded no-progress policy.

Implementation

Only a cursor strictly greater than the current cursor is accepted as progress. Production builds allow 20 consecutive no-progress events; tests use a smaller threshold while exercising the same state transition. Once the threshold is reached, the syncing actor emits the existing ActiveSyncingAborted event and stops, allowing normal maintenance to select another peer without banning it.

The production request timeout remains 20 seconds, so a completely silent peer is bounded at approximately 400 seconds before rotation.

Testing

• RUST_LOG=off cargo nextest run -p fnn --features rocksdb active_sync (10 passed)
• cargo fmt --all -- --check
• cargo clippy --all-targets --features rocksdb -p fnn -- -D warnings