fix: bound batch preflight retries and timeouts

[johntaiko]

Why

• Prevent batch guest input requests from hanging indefinitely when upstream RPC stalls or times out.
• Surface stuck preflight and SP1 network waits as explicit failures instead of leaving tasks stuck in Registered.

How

• Add configurable RPC connect/request timeouts plus bounded retry with exponential backoff in the batch preflight provider.
• Wrap backend request execution with per-request top-level timeouts so stalled guest input or proof jobs resolve to Failed.
• Make SP1 network proof wait timeout configurable and add an early batch preflight log before the first RPC fetch.

Tests

• cargo fmt --all
• cargo check -p raiko-reqactor --features sp1
• cargo check -p raiko-host --features sp1

[Copilot]

Pull request overview

This PR hardens batch preflight/proving execution against upstream stalls by introducing bounded RPC timeouts/retries and top-level request timeouts, so tasks fail explicitly instead of hanging indefinitely.

Changes:

• Add per-request backend timeouts (env-configurable) so guest input/proof/aggregation jobs transition to Failed on stalls.
• Add RPC client connect/request timeouts plus bounded retry w/ exponential backoff for batched RPC fetching in preflight.
• Make SP1 network wait_proof timeout configurable and add an early batch preflight log line before RPC fetching.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

File	Description
reqactor/src/backend.rs	Wraps each request execution in a tokio::time::timeout with env-configurable durations to prevent stuck jobs.
provers/sp1/driver/src/lib.rs	Replaces hard-coded SP1 network wait timeout with an env-configurable function.
core/src/provider/rpc.rs	Introduces RPC client timeouts and a retry helper, applying it to batched block/account/storage/proof fetches.
core/src/preflight/mod.rs	Adds a log line before the first batch preflight RPC fetch for better observability.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[smtmfft]

I think retry isn’t essential (though it doesn’t hurt), as the first timeout error will be caught by the task DB, and a new task will be triggered later by following client requests.