Reuse the cached unsafe SRS in the SNARK test setups #3433

Why

TrustedSetupProvider::with_unsafe_srs regenerates the unsafe SRS on every call even though it already writes it into the content-keyed test cache, so every build_for_test pays minutes of SRS generation that the cache should absorb.
This is the highest leverage optimization of #3405 (SRS reuse alone measured at 75 to 61 minutes nightly in PR #3345).

What

Reuse the SRS file already persisted under target/mithril-circuit-test-cache so SRS generation is paid once per machine and per fingerprint, for both SnarkProverSetup::build_for_test and IvcSnarkProverSetup::build_for_test.

How

• Add a guard in with_unsafe_srs: when the SRS file exists use it
• Replace its direct File::create write with the temp-plus-rename pattern already used by store_srs_bytes_to_file
• Persist the downsized SRS per target degree as well: profiling shows ParamsKZG::downsize (Lagrange basis recomputation) costs about 3x the k=20 SRS generation and is paid on every setup load, warm or cold
• Verify both build_for_test constructors hit the cache on a warm second run
  • Non-recursive: works fine, a test was added to verify that (can be removed)
  • Recursive: works but the warm run is not faster due to keeping the downsizing operation and having a slow ProvingKey deserialization
    • Fix the downize operation always applying
    • Check if the ProvingKey can be generated/loaded faster
• Assess the gain (expected in the action plan: nightly from 75 to ~61 minutes, measured in PR DRAFT: reuse pre-computed data for 3343 #3345) and report it in the issue
  • For now gain looks to be roughly 35 minutes (1h11m => 35min)