feat(p2p): per-peer fork download budget

[nullPointerEnjoyer]

Summary

• Adds a per-peer token budget limiting how many headers a peer can have us process per refill interval (post-IBD). Exhaustion defers processing: no ban, no disconnect, no storage drop; a scheduled header request retry (budget-subject, earliest-deadline, issued at most once per refill interval) recovers deferred data. Deferred lists also clear the stalling expectation, so a deferring peer is never punished for latency.
• New ProtocolConfig knobs (node-local, not transmitted): max_fork_downloads_per_peer (default 2000), fork_download_refill_interval (default 600s). Setting the limit very high restores pre-change behavior.
• Bounds per-peer header-processing work regardless of what a peer announces, while keeping all announced data fetchable. No wire change, no compatibility impact for older peers, no consensus surface.

Test plan

• cargo test -p p2p: 323 tests pass, including 3 new network-sync tests (deferral without punishment + refill recovery, bounded variant announcements, IBD exemption)
• 45+ serial runs of the new tests with 0 failures (retry robustness: loop-body deadline check, earliest-deadline re-arm, retry kept armed across unrelated successful lists)
• ./do_checks.sh green; OCR review clean

[github-actions]

🔍 OpenCodeReview found 2 issue(s) in this PR.

• ✅ Successfully posted inline: 0 comment(s)
• 📋 Routed to summary by policy: 2 comment(s)

---

📄 p2p/src/sync/peer/block_manager.rs (L745-L745)

⚠️ GitHub could not post this as an inline comment: Routed to summary (severity low · category performance)

This chainstate round-trip (is_initial_block_download) runs on every incoming header list, even when the budget is full and the check result is unchanged. Since headers arrive frequently during normal sync, consider caching the IBD flag locally (e.g. refreshed on sync-status changes already handled via handle_sync_status_change) or short-circuiting when fork_download_budget still has full capacity. The existing chainstate_handle.is_initial_block_download() in handle_header_request shows this pattern is already used elsewhere, so it's consistent — but here it's on the hottest inbound path.

💡 Suggested Change

Before:

if !self.chainstate_handle.call(|c| Ok(c.is_initial_block_download())).await? {

After:

// Cheap guard: skip the chainstate round-trip while the budget has full capacity.
if self.fork_download_budget.has_capacity()
    || !self.chainstate_handle.call(|c| Ok(c.is_initial_block_download())).await?
{

---

📄 p2p/src/sync/peer/fork_download_budget.rs (L65-L71)

⚠️ GitHub could not post this as an inline comment: Routed to summary (severity low · category bug)

A sub-second refill interval (e.g. Duration::from_millis(500)) is silently misinterpreted: as_secs() truncates to 0, which hits the degenerate-configuration branch and refills the bucket to full capacity on every call, effectively disabling the budget. Either round the interval up to at least one second (cmp::max(Duration::from_secs(1), self.refill_interval)) or compute fractional rates in milliseconds/sub-second units so short intervals still enforce a bounded rate.

💡 Suggested Change

Before:

        let interval_secs = self.refill_interval.as_secs();
        if interval_secs == 0 {
            // Degenerate configuration: refill instantly.
            self.tokens = self.capacity;
            self.last_refill = now;
            return;
        }

After:

        let interval_secs = self
            .refill_interval
            .max(Duration::from_secs(1))
            .as_secs();
        if interval_secs == 0 {
            // Degenerate configuration: refill instantly.
            self.tokens = self.capacity;
            self.last_refill = now;
            return;
        }