perf: preprocess concurrently to mpc-tls

[themighty1]

(This PR is not in a finished form, it may need some polishing and test)

This PR introduces concurrent preprocessing alongside MPC‑TLS.

Currently, this feature benefits mostly preprocessing the OT setup for QuickSilver, since the execution of QS starts only at the very end of MPC-TLS.

The following changes were made to accommodate this feature:

mpz changes

in this branch: refactor/zk_expose_ot_handle
(I'll discuss the changes here to keep the discussion in one place)

• Expose OT handles to the ZK prover and verifier.

  • Allows external code to lock and drive OT in advance.
  • Caveat: callers must avoid simultaneous locks (consider behind a feature flag).

• Support multiple independent contexts sharing a single yamux muxer with unique thread/stream IDs.

  • Necessary so preprocessing and MPC‑TLS can both use the same muxer concurrently.

tlsn changes (in this PR)

• Add a "limited" mode to the DEAP VM (better naming is welcome)

  • Disables any ZK‑VM operations that would conflict with in‑flight OT preprocessing.

• Auxiliary‐future polling

  • MuxFuture can now drive a user‐supplied future (e.g. the OT preprocessing task) alongside the main MPC‑TLS future.

• KOS‑driven OT for key exchange

  • Before:
  
  • Now:
  
  • The key exchange’s small OT requirement is served directly by KOS—incurring minimal extra work but eliminating one round‑trip to Ferret and simplifying OT ownership and locking.

Benchmarks

The improvements start to show when the server payload size is sufficiently large, i.e > 10KB. For a 20KB payload the improvement was ~15%.

Before this PR  the runtime was 7000 ms on average 

latency,,20,200,2048,20000,true,4796,2263,7093,61483178,3378041,2555529,329257,64107406,3707310,

After this PR  the runtime was 6100 ms on average

latency,,20,200,2048,20000,true,3953,2185,6177,61494688,3378137,2556207,329257,64119594,3707406,

[sinui0]

I don't feel like the additional complexity + interface leakage is justified here. Besides that, the current thinking was that the OT processing for proving the received ciphertexts is getting moved to after the connection closes and the user provides configuration for what to reveal/commit to. Proving the plaintext may not need to occur at all