sync: propagate serving peer hint through gossip and cached-descendant paths

## Context

From PR #909 review (ch4r10t33r, item #7).

PR #909 added `preferred_peer` routing for checkpoint/parent walks and blocks-by-range, but gossip block processing and cached-descendant retry paths still pass `null` to `flushPendingParentFetches`. This means those paths always use random peer selection.

## Proposal

Thread the originating peer through gossip block handling and `processCachedDescendants` so the peer hint is available when flushing parent fetches. Requires plumbing `peer_id` through callback contexts that currently don't carry it.

## Trade-offs

The throughput trade-off documented in `flushPendingParentFetches` (single-peer concentration vs parallelism) applies. For gossip blocks that arrive from many peers, random selection may actually be preferable — evaluate before blindly threading the hint everywhere.

Related: PR #909

Start with flushPendingParentFetches, the gossip block handling path, and processCachedDescendants, then review PR #909 and its item #7. Trace where callback contexts currently lose peer_id and evaluate whether preserving the originating peer is appropriate for gossip and cached-descendant retries. Done means the routing behavior and throughput trade-off are resolved for both paths.

Written by the indexing model from the issue text.