Request: increase upload size limit for dynamic-waas-sdk-mpc-sys

**Crate:** `dynamic-waas-sdk-mpc-sys` (about to be published — slot reserved) **Owner (initial):** @gfarrisi (will transfer to a `dynamic-labs` org/team after first publish) **Repository:** https://github.com/dynamic-labs/dynamic-waas-sdk **Requested limit:** **30 MiB** per crate **Current `.crate` size:** 20.1 MiB compressed (68.5 MiB uncompressed) ## Why we need it `dynamic-waas-sdk-mpc-sys` is the `-sys` crate for Dynamic's wallet-as-a-service Rust SDK. It bundles four prebuilt static libraries (`libdynamic_waas_mpc.a`) — one per supported target: | Target | Compressed contribution | |---|---| | `x86_64-unknown-linux-gnu` | ~5.9 MiB | | `aarch64-unknown-linux-gnu` | ~5.8 MiB | | `x86_64-apple-darwin` | ~3.5 MiB | | `aarch64-apple-darwin` | ~3.3 MiB | Each library is the compiled output of an MPC (multi-party computation) cryptography stack. The build pipeline (in `.github/workflows/rust-sdk-prebuild-mpc.yml`) produces the libs reproducibly on per-arch GitHub-hosted runners. They're already stripped of debug info — `llvm-strip --strip-debug` shaves <0.1% off, so we're at the binary floor. ## Why not split We considered splitting into per-target sys crates (`-x86_64-linux`, `-aarch64-linux`, etc.). It works but adds permanent multi-crate version coordination and shows up as a confusing extra crate in users' `Cargo.lock`. We'd rather publish the canonical layout if the size bump is approvable. ## Why not build-from-source The upstream MPC implementation is closed-source / private Cargo registry. End users can't build from source. Customer-side `cargo build` *must* link against the prebuilt — that's the design. ## Republish cadence Low — semver-versioned SDK releases, expected ~quarterly. We won't churn the registry with frequent large uploads. Happy to provide more context if useful. Thanks!