Harden the SRS download of `TrustedSetupProvider`

## Why

The SRS is downloaded in a single blocking request, fully buffered in memory before being hashed, with no retry. A transient network error fails the whole startup, and the memory peak is proportional to the SRS size.

The same code pulls `reqwest` and a TLS backend into a cryptographic library, which drives the feature complexity of `mithril-stm` and its wasm story. Deciding where the SRS acquisition belongs shapes how the hardening is done, so both are handled together.

## What

Make the download resilient and bounded in memory, re-verify what is served from the cache, and settle whether the SRS acquisition stays in `mithril-stm`.

## How

- [ ] Inventory the callers of `TrustedSetupProvider` and what they would need to provide instead
- [ ] Assess the impact on the wasm target and on the feature flags of `mithril-stm`
- [ ] Decide whether the SRS acquisition moves out of `mithril-stm`, and record the decision with a target location and an interface for the parameters provider
- [ ] Stream the download and compute the SHA-256 hash incrementally (`circuits/trusted_setup.rs`)
- [ ] Add bounded retries with backoff on a transient download error
- [ ] Re-verify the hash of a cached SRS file, if the cost is acceptable, and decide whether it is done on every load or on a schedule
- [ ] Report a clear error distinguishing a network failure from a hash mismatch

Start with circuits/trusted_setup.rs, then inventory every TrustedSetupProvider caller and the parameters each would need to provide. Assess the wasm target and mithril-stm feature flags before choosing whether SRS acquisition moves out. Done means the target location and parameters-provider interface are recorded, streaming and retry behavior are defined, cached data is re-verified, and network and hash errors are distinct.

Written by the indexing model from the issue text.