• Adds run_v2() methods to epoch sync, header sync, and block sync that the V2 sync handler can call without the V1 side effects (status mutation, mode switching, state-sync-needed checks). The V1 run() methods are preserved and still used by the V1 handler — no behavioral changes for V1.
• Adds handle_sync_needed_v2() — the V2 sync handler that implements a single linear pipeline: EpochSync → HeaderSync → StateSync → BlockSync. Gated behind SYNC_V2_ENABLED (currently false).

Why new run_v2() methods instead of modifying the existing ones?

The V1 run() methods mix orchestration with execution: they read and write SyncStatus, decide whether to trigger other sync phases (e.g. block sync's check_state_needed can trigger state sync), and contain mode-dependent logic (e.g. header sync's Primary/Background/Skip modes based on current status).

V2 needs components that just do their work and report back — the handler owns all status transitions. Rather than adding feature flags inside each run(), we extract the core logic into run_v2() methods with cleaner signatures:

• EpochSync::run_v2(&mut EpochSyncStatus) — takes the inner EpochSyncStatus directly instead of &mut SyncStatus. The V1 run() now delegates to run_v2() after extracting the status.
• HeaderSync::run_v2(chain, highest_height, peers, ban_stalling_peers) — self-contained header sync tick. Structured around syncing_peer presence: if a request is in flight, checks batch completion or stalling; if idle, picks a peer and sends a request. Does not touch SyncStatus. When ban_stalling_peers is true (primary HeaderSync phase), bans stalling peers inline before clearing them — avoiding the peer-identity-loss issue that would occur if the peer were cleared first. V1's run() and header_sync_due() are unchanged from master.
• BlockSync::run_v2(chain, peers) — requests blocks if due. Does not check state_needed (V2 never falls back to state sync from block sync). Extracted block_request_due() from block_sync_due() — the latter adds the check_state_needed guard used only by V1.

handle_sync_needed_v2 — the V2 handler

The V2 handler replaces V1's waterfall (run everything top-to-bottom each tick) with an explicit state machine: a single match on SyncStatus that calls the appropriate component and writes the next status on transition. The handler enters at EpochSync (far horizon) or BlockSync (near horizon) based on is_epoch_sync_needed(), and progresses linearly through the pipeline.

Key differences from V1:

• Entry decision made once — decide_initial_phase() runs only when transitioning from NoSync/AwaitingPeers. V1 re-evaluates every tick.
• No StateSyncDone — transitions directly StateSync → BlockSync.
• No should_state_sync / check_state_needed — state sync only happens on the far-horizon path, never as a fallback from block sync.
• No reset_data_pre_state_sync — stale nodes wipe DB via process restart.
• Header sync only where needed — called during HeaderSync and BlockSync phases, not every tick with mode switching.

Currently gated behind SYNC_V2_ENABLED = false — will be enabled in a follow-up PR after test validation.

Other changes

• EpochSync::is_epoch_sync_needed() — extracted the horizon check and stale-node gate from run() into a pure query method. Adds an archival node guard (archival nodes must not epoch sync). Changes the stale-node gate from ContinuousEpochSync to SYNC_V2_ENABLED.
• archive field on EpochSync — new archive: bool field (passed from config.archive via client.rs) so is_epoch_sync_needed() can reject epoch sync for archival nodes.
• SYNC_V2_ENABLED constant — replaces ProtocolFeature::SyncV2. Sync versioning is a node-local concern (which code path to run), not a protocol concern (what messages/blocks are valid). The constant lives in sync/mod.rs and is set to false.
• Stale-node shutdown gate — in the EpochSyncResponseMessage handler, the gate that triggers data-reset shutdown changed from ProtocolFeature::ContinuousEpochSync to SYNC_V2_ENABLED.
• neard/cli.rs — check_epoch_sync_data_reset_marker now checks SYNC_V2_ENABLED instead of ProtocolFeature::ContinuousEpochSync.

Follow-ups

• Test-loop tests — dedicated V2 sync tests (far-horizon full pipeline, near-horizon block sync, stale node shutdown, archival skip, etc.) will be added in a follow-up PR once the handler is validated.
• V1 cleanup — once V2 is proven stable, ~600 lines of V1-only code can be removed: handle_sync_needed_v1, should_state_sync, check_state_needed, reset_data_pre_state_sync, HeaderSyncAction enum, block_fetch_horizon config, and the Primary/Background header sync mode distinction.