fix(archiver): keep the stream watchdog above the eth client's fetch retry budget

[DylanVerstraete]

Sixth (and smallest) PR of the archiver liveness audit (finding 6). Stacked on #1348 → #1347 → #1346 → #1345 → #1344; retarget to usc-dev as those merge.

Problem

eth::Client::try_fetch_block retries a block fetch for 5 sweeps over [primary, fallbacks…] with 10/20/40/60 s back-off: 130 s of waiting before it gives up. The archiver's stream watchdog (--stream-timeout-secs) defaulted to 120 s. On a block that only a fallback can serve, or a primary that is flapping, the watchdog tore the stream down (reconnect, anchor check, re-subscribe) 10 s before the client would have either succeeded through a fallback or surfaced the real error. With #1348 wiring fallbacks into the archiver this mismatch would have made them mostly pointless.

Changes

• Default --stream-timeout-secs 120 → 180.
• The flag is now NonZeroU64: 0 produced an immediate timeout and an endless reconnect loop.
• The relationship to the client's retry budget is documented on the flag help and in the README.

No behaviour change for deployments that set the flag explicitly (other than rejecting 0).

Verification

cargo test -p archiver (36), clippy -D warnings, fmt.

[cursor]

PR Summary

Low Risk
Config default and validation tweak for stream stall timing; no auth or data-path changes, and explicit operator values behave the same except 0 is no longer allowed.

Overview
Raises the archiver root-stream watchdog default --stream-timeout-secs from 120 → 180 so it stays above the eth client’s ~130 s block-fetch retry window (primary + fallbacks with back-off). Without that gap, the watchdog could tear down and rebuild the stream while a fetch was still cycling fallbacks, undermining RPC fallback behavior.

The flag is now NonZeroU64 (rejecting 0, which caused immediate timeouts and reconnect loops). Help text and the README config table describe the watchdog as “no new root” stall detection and document the relationship to the client retry budget. main.rs uses .get() when building the timeout duration.

^{Reviewed by Cursor Bugbot for commit ecf9ecc. Bugbot is set up for automated code reviews on this repo. Configure here.}