Implement backend-backed MultiSigStateStore for cross-process signer coordination

[bbjiggy]

Description

Follow-up from the #79 spike (see docs/spikes/issue-79-retry-session-multisig.md).

MultiSigEscrowClient keeps operation state in an in-memory Map, scoped to one process. Per the
README, signers are expected to submit their signed XDR independently, which requires state
visible across processes. The spike defined the target abstraction, MultiSigStateStore (in
src/types/multisig.ts), and added exportState/importState as a non-breaking stopgap, but did
not implement a real backend-backed store since that requires new backend endpoints.

Proposal

1. Add backend REST endpoints for multisig operations: create, add-signature, get-status
   (mirroring the current MultiSigEscrowClient sync methods), authorized via the existing
   auth/session token.
2. Implement MultiSigStateStore in the SDK against those endpoints.
3. Wire it into MultiSigEscrowClient as an injectable store (defaulting to the current in-memory
   Map for local/offline use).

Note

Every MultiSigEscrowClient method is currently synchronous. Wiring in an async store is a
breaking API change (methods become Promise-returning) and should ship behind a major version
bump, with the sync in-memory path kept available for local testing.

Acceptance Criteria

• Backend multisig-operation endpoints exist and are documented
• SDK MultiSigStateStore implementation against those endpoints
• MultiSigEscrowClient accepts an injectable store (async), default remains in-memory
• Migration notes for the breaking (sync -> async) API change