Harden the SRS download of `TrustedSetupProvider`

[jpraynaud]

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