refactor(crypto): implement dynamic salt and support multiple keys/algorithms

[DharunMR]

Summary

This PR completes a major architectural upgrade to the cryptography engine by supporting multiple keys/algorithms and generating dynamic salts per secret. During the implementation of these features, several critical bugs and redundancies in the AES-GCM and AES-CFB implementations were identified and fixed

• Dynamic Routing: EncryptedData now stores Algorithm and KeyVersion metadata. engine.go reads this metadata during decryption to dynamically route the payload to the correct algorithm (GCM vs CFB) and fetch the specific key version from the keystore.

• Seamless Rotation: This allows administrators to rotate default keys in the configuration; new secrets will use the new key, while old secrets will still decrypt perfectly using the stored KeyVersion.

• Engin Driven Entropy: engine.go now securely generates a fresh 16-byte random salt (rand.Read) for every encryption request and stores it securely in the DB record.

• CFB Upgraded: aes256cfb.go now accepts this dynamic salt for Argon2 key derivation, drastically improving cryptographic security against pre-computed attacks compared to the old hardcoded legacySalt.

• Resolved "Double-Storage": Previously, GCM prepended the 12-byte nonce to the ciphertext, while engine.go was also storing that exact same salt in the database. Encrypt now passes nil to gcm.Seal for the destination array, removing the redundant prepended nonce and reducing the database footprint per secret.

• Safely Handled Keystore Newlines: Legacy CFB local keystores contain trailing newlines (\n). Passing these raw strings to Go's strict Base64 decoder caused GCM to panic. decodeKey now utilizes strings.TrimSpace(string(key)) before Base64 decoding, preventing crashes while maintaining absolute backward compatibility for CFB.

[coveralls]

coverage: 59.534% (-0.005%) from 59.539% — DharunMR:enhancement-in-crypto-engine into mindersec:main