Add vetkey helpers to Call.mo (vetkd_public_key, vetkd_derive_key)

[marc0olo]

Background

mo:ic already exposes the raw vetkd_public_key and vetkd_derive_key IC management canister methods (present since v3.0.0). However, calling them correctly requires knowing how many cycles to attach — the same friction that motivated the existing http_request, sign_with_ecdsa, and sign_with_schnorr helpers in src/Call.mo.

Currently, developers who need vetkey calls either:

• Call the raw methods manually and figure out cycle math themselves, or
• Reach for mo:ic-vetkeys/ManagementCanister — an extra dependency whose ManagementCanister.mo is essentially a thin cycle-attaching wrapper around the same IC methods that are already in mo:ic.

This was discussed in #10 and PR #11.

Proposal

Add vetkdPublicKey and vetkdDeriveKey helpers to src/Call.mo, following the same pattern as the existing ECDSA/Schnorr helpers:

public func vetkdPublicKey(args : T.VetkdPublicKeyArgs) : async Blob {
  let result = await ic.vetkd_public_key(args);
  result.public_key
};

public func vetkdDeriveKey(args : T.VetkdDeriveKeyArgs) : async Blob {
  let result = await (with cycles = VETKD_DERIVE_KEY_COST) ic.vetkd_derive_key(args);
  result.encrypted_key
};

(Cycle cost to be confirmed against the current IC pricing — mo:ic-vetkeys uses 26_153_846_153.)

Consistency argument

Every other IC management canister method that requires cycle attachment already has a helper in Call.mo:

Method	Helper in Call.mo
http_request	✓
sign_with_ecdsa	✓
sign_with_schnorr	✓
vetkd_public_key	✗
vetkd_derive_key	✗

Vetkey is the only such method without one. This forces an extra package dependency (mo:ic-vetkeys) for something that is structurally identical to the ECDSA/Schnorr helpers already present.

Relationship to mo:ic-vetkeys

mo:ic-vetkeys provides more than just wrappers — it also includes higher-level crypto utilities (signWithBls, BLS key operations, threshold encryption helpers). Those remain the right home for advanced vetkey functionality. The proposal here is only to cover the basic "call the IC method with the right cycle attachment" layer, consistent with what Call.mo already does for other methods.