[testnet] Use streaming DownloadBlobs RPC for batch blob downloads

[ndr-ds]

Motivation

The streaming DownloadBlobs validator endpoint was backported to
testnet_conway in #6156, but nothing on the client uses it yet — chain
sync still downloads blobs one unary download_blob RPC at a time. This PR
backports the caller so testnet_conway clients (notably the PM workers)
benefit from the streaming endpoint.

Proposal

Client-side only. Cherry-pick of the main change (#6157):

• download_blobs issues one streaming DownloadBlobs request per validator
  (tried in shuffled order) carrying all still-missing blob IDs, instead of
  one unary RPC per blob. Falls back to the next validator only for IDs not
  yet returned, preserving partial progress.
• The per-attempt deadline is progress-based: blob_download_timeout bounds
  the wait for the stream to open and for each subsequent item, so a stalled
  peer is abandoned quickly while a transfer that is still making progress is
  never cancelled. (A whole-attempt cutoff would make batches larger than ~1s
  of transfer time permanently undownloadable with the default setting.) Flag
  docs and CLI.md updated to match.
• Deduplicate requested blob IDs up front (BTreeSet) so a repeated ID can't
  abort the stream and fail the batch — process_certificates does pass
  duplicates, since it flat-maps required_blob_ids across certificates.
• An attempt that ends because the peer sent an unexpected or duplicate blob
  counts as a failed interaction in that peer's EMA metrics.

Unlike #6157, this backport does not remove the now-unused per-blob
client path (RemoteNode::download_blob, RequestKey::Blob,
RequestResult::Blob) — keeping the backport surface minimal.

What this optimizes (and what it does not). This reduces client→validator
RPC fan-out from N unary calls to one streamed call per validator. It does
not reduce validator-side storage work: the handler still performs N
parallel single-partition point reads, because each blob lives under its own
root_key partition and can't be coalesced into a single IN query. That
storage cost is also largely irrelevant in practice — the proxy serves these
blobs ~99.8% from its in-memory cache (testnet-conway production,
linera_read_blob cache vs db over 24h). The win therefore scales with the
number of blobs per batch: meaningful for blob-heavy cold syncs (PM
market/worker chains), a no-op for blob-light root chains.

No protocol/storage-format change; the server side is unchanged and already
deployed on testnet_conway.

Test Plan

• No regression on blob-light chains (measured). Fresh-wallet/fresh-DB
  sync of root chain d45db728… (8000 blocks), old vs new binary, both
  ~16 blocks/s. That sync pulled exactly one blob (ChainDescription at
  genesis), so the batching has nothing to collapse — as expected for root
  chains.
• Expected win on PM chains (not yet measured end-to-end). Production
  linera_write_blob shows PM workers writing 50k–230k blobs per ~2-day
  cold-start window; each was a separate unary RPC before, and now streams.
  A head-to-head blocks/s number requires PM wallet keys or a local net with
  a published app + cross-chain blob traffic; tracked as follow-up.
• cargo test -p linera-core --lib requests_scheduler (27 tests) and
  cargo clippy clean; CLI.md regenerated.

Release Plan

• These changes follow the usual release cycle for testnet_conway
  (client-side only; the server endpoint [backport] Add streaming DownloadBlobs RPC endpoint (#5976) #6156 is already deployed, so no
  validator hotfix is needed).

Links

• Forward PR on main: Use streaming DownloadBlobs RPC for batch blob downloads #6157
• Server endpoint backport: [backport] Add streaming DownloadBlobs RPC endpoint (#5976) #6156
• reviewer checklist