[ENHANCEMENT] Hash API keys used internally for caching #634

Description

Right now, some SDK persistence mechanisms use the raw SDK/API key directly in local persistence metadata (for example cache filenames or UserDefaults keys).

Even though this may not expose the key publicly, it means sensitive identifiers are persisted on disk in plaintext. For teams with stricter security or compliance requirements, this creates unnecessary risk and makes auditing harder.

Benefits

This reduces plaintext SDK key exposure from local storage with minimal implementation footprint — a single String extension and callsite changes; and no new public API surface, making it straightforward for the SDK team to review and adopt.

Detail

Hash the SDK key internally before using it as a persistence identifier, using SHA-256 via CryptoKit. Persistence identifiers would then be derived from sdkKey.sha256Hash rather than the raw key. This would apply to:

• Datafile cache key / filename generation
• UserDefaults keys for last-modified metadata
• Any other persistence identifiers derived from the SDK key

This is technically a breaking change for existing cache entries. The consequence is a one-time cache miss on first launch after upgrading — the datafile is re-fetched and last-modified metadata is reset. For most apps this is acceptable and avoids the complexity of a migration path.

Examples

import CryptoKit

extension String {
    var sha256Hash: String {
        let digest = SHA256.hash(data: Data(utf8))
        return digest.map { String(format: "%02x", $0) }.joined()
    }
}

Callsite usage would simply replace raw sdkKey references with sdkKey.sha256Hash wherever persistence identifiers are generated.

Risks/Downsides

• One-time cache miss for existing users on upgrade (datafile re-fetched, last-modified reset)
• Not user-configurable — a fixed SHA-256 derivation is applied internally