fix(net): separate block fetch eligibility and scheduling

[317787106]

What does this PR do?

Pending transaction requests currently exclude otherwise available block providers, and unordered scheduling can reserve the only provider for a later block. Introduce block-specific idleness and shared provider eligibility, reserve providers in block-height order, and retain blocks without an eligible source for a later pass.

Initial requests prefer smaller batches in the current scheduling pass. Backups prefer lower fetch-latency P75 without a hard latency cutoff and dispatch only after the actual short timeout or the existing faster-provider condition. Make the in-process sync-block set concurrent.

Why?

Block fetching should remain available during transaction downloads and should prioritize earlier available blocks while retaining usable backup providers.

Split scope

Independent split 3 of #91, based directly on release_v4.8.3. It does not require the provider-accounting PR (#97) or validated-INV PR (#98). Retry-state retention, the two-request bound, disconnect recovery, and registration/worker races remain together in the fourth PR, to be proposed after the first three merge.

When combining with #98, retain both the monotonic activity updater and the idle-method documentation at the overlapping insertion in PeerConnection; this merge was verified locally.

Existing idle API semantics remain unchanged; new eligibility APIs are additive and Java 8 compatible. No dependencies, wire/storage formats, or configuration change.

Validation

• ARM64/JDK 17: 28 focused and existing regression tests passed.
• checkstyleMain checkstyleTest passed; Semgrep found no issues in changed files.
• Local integration rehearsal of all three splits: 159 networking tests and Checkstyle passed.
• Repository-wide test: 3,461 tests, 26 skipped, zero failures/errors.
• Local worktree commands skip :framework:generateGitProperties because the existing metadata plugin cannot resolve linked worktrees.