feat: create near-mpc-sdk crate with types for sign requests

[DSharifi]

stacked on top of #2199

closes #2159

Creates a new crate, near-mpc-sdk, which is meant for users that want to call the mpc contract.

This PR adds types for building sign request payloads, and deserializing responses.

Testing

• Unit test added to the sign module in the new crate
• The sandbox integration tests in for the contract have been changed to use the SDK for building payloads, and responses.

[DSharifi]

@claude pleas re-review this PR

[gilcu3]

@claude pleas re-review this PR

@claude review

[gilcu3]

LGTM.

Left a questions about the pattern used

[claude]

Code Review: near-mpc-sdk crate for sign requests

I reviewed the diff against main, checked serialization compatibility, name collision risks, and adherence to engineering standards.

Findings

Serialization compatibility between the new SDK Payload (using BoundedVec<u8, L, U> + hex_serde) and the contract's Payload (using Bytes<L, U>) is fine — both serialize to hex strings with identical bounds. The new SignRequestArgs (non-optional domain_id, no legacy fields) produces JSON the contract accepts correctly via its TryFrom validation.

No critical/blocking issues found. A couple of minor observations:

• pub use sign::* in contract-interface/src/lib.rs: This adds SignRequestArgs and Payload to the contract_interface::types namespace. Currently no downstream code imports those names from there, so no collision today. But these names are also defined internally in mpc-contract::primitives::signature. If any future code does use contract_interface::types::Payload, they'll get the SDK version (with BoundedVec) rather than the contract version (with Bytes). The types are serialization-compatible, so this is not a bug — just worth being aware of for maintainability. A more explicit re-export (e.g., pub use sign::{SignRequestArgs, Payload};) instead of glob would make the public API surface more intentional.

• Builder enforces ordering (path → payload → domain_id): The typestate pattern is clean but forces a specific call order. This is a design choice, not a bug. If flexibility for callers matters, the methods could be made available on any state where the field isn't yet set. Fine as-is for an initial version.

✅ Approved — no blocking issues.

[netrome]

Nice stuff. I think the EDDSA bounds need a better explanation but that's my only blocker.