fix: ~ecdsa_preprocessing_data cleanses over live std::map/std::vector members (UB + leak)

[grecow]

Problem

ecdsa_preprocessing_data (in include/cosigner/cmp_ecdsa_signing_service.h) has:

~ecdsa_preprocessing_data() { OPENSSL_cleanse(k.data, sizeof(ecdsa_preprocessing_data)); }

k is the first member, so k.data aliases the object base — but the size passed is
sizeof(ecdsa_preprocessing_data), i.e. the entire struct. That span covers the three
non-trivially-destructible members:

byte_vector_t                                  mta_request;   // std::vector
std::map<uint64_t, byte_vector_t>              G_proofs;      // std::map
std::map<uint64_t, ecdsa_signing_public_data>  public_data;   // std::map

A user-declared destructor body runs before the implicit member destructors, so the
OPENSSL_cleanse zeroes the live control blocks of the vector and the two maps
(begin/end/root pointers, node counts). The subsequent ~vector / ~map then run on those
zeroed internals — undefined behaviour, and in practice a heap leak of every map node
and vector buffer (these are populated per-signing from peer messages).

Fix

Cleanse each secret scalar individually and let the containers destruct normally. This mirrors
the correct pattern already used by the EdDSA analog eddsa_signature_data
(include/cosigner/eddsa_online_signing_service.h), which cleanses sizeof(k.data) rather than
the whole struct.

Notes

• Behaviour-preserving for the intended goal (all secret scalars k, gamma, a, b, delta, chi
  are still wiped); only the erroneous over-write of the live container internals is removed.
• This is a correctness / memory-hygiene fix — not a remotely exploitable issue (the write stays
  within the object; no OOB).
• Suggested validation: build with -fsanitize=address and run ecdsa_online_test /
  ecdsa_offline_test; LeakSanitizer flags the orphaned allocations before this change and is
  clean after.