Problem

Our API keys default to sha384 signatures, but the SDK's private _calcSignature() currently accepts an algorithm argument. That makes it possible for consumers (or downstream wrappers) to generate sha1 signatures from the SDK surface, which can fail against accounts/keys configured for sha384 and causes avoidable auth failures.

Expected behavior

The SDK should consistently generate sha384 signatures for signed requests.

Proposed fix

• Remove algorithm override support from _calcSignature() and always sign with sha384.
• Add a regression test to ensure we keep emitting sha384 even if an extra algorithm argument is passed.
• Document in README that calcSignature() returns sha384 signatures.

Context

This aligns SDK behavior with modern API key defaults and avoids signature-algorithm drift in downstream integrations.