fix(elasticache): empty engine fails dedupe open; Redis OSS RIs covering Valkey recs aren't deduped

[cristim]

Follow-ups from the review of #149 (closes #66):

• providers/aws/services/elasticache/client.go ~100: a reservation with a nil ProductDescription gets Engine "", so its dedupe key never matches and the check fails open. Log a warning, and treat an empty engine as matching any engine for the cache service (fail closed).
• AWS lets Redis OSS reserved nodes cover Valkey nodes. A manually bought Redis RI won't dedupe a 'valkey' recommendation. Normalize redis and valkey to one engine family for ElastiCache dedupe.
• Nit: memorydb/client_test.go claims to catch parser drift but hardcodes 'redis' instead of building the rec through parseMemoryDBDetails.

[cristim]

Verified after merge of #158 at b3b4cb5e3d806f479d14e24872dfe57a4201c73f.

• The merged tree is identical to independently reviewed head 9b5ca4d61d2afe05ffca9109244dc225820297ef (tree 005485bdcbd687a726b1a3811efa03437813f326).
• On the exact merged checkout, Go 1.26.6 uncached race tests passed for named ElastiCache engine budgets, service/provider boundaries, missing-engine warnings, CE parser-to-SDK reservation dedupe, AWS reservation states, shared provider dispatch and GCP duplicate purchase/identity cases across five affected packages.
• The integrated MemoryDB import and both GCP/ElastiCache test groups remain intact. No broad test-suite reruns or cloud purchases were used for this post-merge check.

This is local verification of real library paths with injected SDK fixtures, not live-cloud evidence. Both main-branch CI workflows are running and tracked separately. Published shared-package dependency updates remain tracked in #154; consumers need updated module pins to receive the changes.