fix(zakura): allow four unproven block probes

[evan-forbes]

Motivation

Split out of #435.

An unproven Zakura block-sync peer currently gets only one GetBlocks probe before it must deliver an accepted body to receive more work. That is too brittle for a single-peer sync path: one lost/delayed initial response can leave the peer capped until the no-progress liveness deadline disconnects it.

Regtest also needed a shorter body-sync stall watchdog so a stalled node reaches the fallback within the e2e test budget.

No linked issue.

Solution

• Shorten the Zakura body-sync stall watchdog on regtest.
• Raise the default unproven peer probe cap from one GetBlocks request to four.
• Keep the existing proof rule: a peer is still unproven until it delivers an accepted body.
• Keep the existing liveness rule: a peer that never serves bodies is still disconnected by the normal no-progress deadline.
• Add focused coverage that the default permits four unproven probes and still disconnects a silent peer.
• Add the changelog entry for the single-peer wedge fix.

Tests

• cargo fmt --all -- --check
• cargo test -p zebra-network block_liveness
• GitHub PR checks are passing as of 2026-07-03, including Unit Tests, Lint, Docs Check, Test Crate Build, Test Docker Config, and Zakura E2E.

Specifications & References

• Split out of fix(zakura): single-peer sync wedge and block-sync backpressure busy-spin #435.

Follow-up Work

None planned.

AI Disclosure

• No AI tools were used in this PR
• AI tools were used: Codex was used to split fix(zakura): single-peer sync wedge and block-sync backpressure busy-spin #435 into focused branches/PRs, run targeted validation, inspect CI, and update this PR description.

PR Checklist

• The PR title follows conventional commits format: type(scope): description
• The PR follows the contribution guidelines.
• This change was discussed in an issue or with the team beforehand.
• The solution is tested.
• The documentation and changelogs are up to date.

[evan-forbes]

noticed a comment from @p0mvn who was debugging a flakey test

this is in a similar vein to #432, where we're hacking around the problem for now.

why the messages we're sending are not working the way we think they are working is tbd.

[evan-forbes]

see #441 where we're gathering more info to debug fully

[evan-forbes]

closing for now