perf(zakura): trim bbr fill-loop overhead

[evan-forbes]

Motivation

CPU profiles during fast sync showed avoidable overhead in two Zakura block-sync paths:

• BbrState::has_fresh_bdp only needs to know whether fresh BDP samples exist, but it recomputed BDP by scanning both BBR sample windows on every byte-mode fill-loop iteration.
• BlockSyncReactor::trace_sync_state ran expensive peer, floor-gap, and work-queue diagnostics on every sequencer view change, including per-commit progress updates.

Solution

• Track the newest timestamp in each BBR WindowedSamples set so has_fresh_bdp is an O(1) freshness check instead of two window scans.
• Thread the fill-loop's existing Instant through slot and byte-headroom checks, avoiding repeated Instant::now() calls and keeping one iteration internally consistent.
• Split block-sync state tracing into detailed periodic/startup rows and lightweight per-view rows. Per-view rows still report commit pipeline progress, but skip peer/floor/work-queue diagnostics.
• Add a changelog performance entry.

The per-view trace rows are deliberately diagnostic-light: fields that require registry/work-queue walks, such as outstanding and queue/needed/slot summaries, are sampled on detailed periodic rows instead of every sequencer view change.

This complements #437: that PR reduces no-op sequencer view wakeups, while this PR reduces the CPU cost of legitimate wakeups and fill-loop iterations.

Validation

• cargo fmt --all -- --check
• git diff --check
• cargo test -p zebra-network bbr
• cargo check -p zebra-network --all-targets
• cargo clippy -p zebra-network --all-targets -- -D warnings
• Checked merge compatibility with fix(zakura): avoid no-op sequencer view wakeups #437 using git merge-tree against the working-tree commit and origin/pr/437

Issue

No linked issue.

AI Disclosure

Used Codex to implement the BBR freshness fast path, reduce per-view trace diagnostics, compare with #437, run validation, and draft/update this PR description.

[evan-forbes]

this might be duplicate to some of what @p0mvn found and was working on, apologies if so, happy to close