feat(aws): storage.elasticache — elasticache-alpha port [stacked on #150]

[so0k]

Storage slice PR 8 — storage.elasticache: the @aws-cdk/aws-elasticache-alpha port (v2.263.0-alpha.0)

Stacked on #150. First alpha-package port of the slice: all 9 upstream files into storage.elasticache, 190 tests.

Scope honesty (deliberate narrowness)

The upstream alpha covers ServerlessCache + Users (IAM/Password/NoPassword) + UserGroup only — there is no upstream L2 for classic clusters or replication groups, and none was invented here. An alpha-churn tracker comment heads the barrel: this module must be re-diffed against upstream on every reference-tag bump (experimental surfaces churn without deprecation cycles).

Alpha-specific mechanics

• elasticache-grants.generated.ts reconstructed as genuine TS from the built @aws-cdk/aws-elasticache-alpha@2.263.0-alpha.0 bundle (the file is gitignored upstream, generated by projen grants codegen — spec2cdk does not emit grants); wiring mirrors the sqs-grants precedent, grant actions verified byte-for-byte.
• The alpha's aws-cdk-lib/interfaces marker imports (IServerlessCacheRef etc.) are stripped with TODO permalinks — same pattern as the rds/docdb *Ref omissions, with a local structural-typing shim where the grants file needs the shape.

Mapping notes

• UserGroup.addUser uses the L1's inline user_ids (no separate association resource needed — CFN's UserIds is inline too; documented deviation).
• User/user-group ids get gridUUID-lowercased defaults (AWS lowercase constraints — the feat(aws): storage.rds DatabaseProxy + ServerlessCluster v1 (deprecation-kept) [stacked on #148] #149 proxy lesson applied preemptively); IamUser's userName==userId invariant survives lowercasing with a self-explanatory error for mixed-case inputs.
• Number-typed endpoint port tokens; serverlessCacheStatus read-back restored after the adversarial verify caught a false "provider doesn't expose it" omission claim (the only major finding — the L1 does expose status).
• Backup-time rendering (Schedule → daily_snapshot_time) and the full cacheUsageLimits surface are regression-tested beyond upstream's own coverage.

Live integ (make elasticache.serverless-cache) — receipts in thread

Port of upstream's own integ.serverless-cache.ts: real Valkey 8 serverless cache with KMS key, security groups, backup settings, usage limits (1 GB / 1000–2000 ECPU), an IamUser (on ~* +@all) in a UserGroup attached to the cache. Validates upstream's same describeServerlessCaches assertions plus user/user-group read-backs, drift oracle, destroy.

[so0k]

Live apply/verify/destroy receipts — make elasticache.serverless-cache (aws-vault → tcons-vincent, us-east-1)

Run 3 (final, kms ARN fix) — PASS 636.31s, first-attempt apply:

TestElasticacheServerlessCache 02:40:03 Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
elasticache_serverless_cache_test.go:52: serverlesscache available (valkey 8 at serverlesscache-....serverless.use1.cache.amazonaws.com:6379, limits applied)   <-- usage limits 1GB / 1000-2000 ECPU read back
elasticache_serverless_cache_test.go:63: user cacheuser active (iam auth)
elasticache_serverless_cache_test.go:72: user group usergroup contains cacheuser
(drift oracle: tofu plan -detailed-exitcode == 0 — clean)
TestElasticacheServerlessCache 02:46:06 Destroy complete! Resources: 14 destroyed.
--- PASS: TestElasticacheServerlessCache (636.31s)

Run 2 — live-caught construct defect (10th live-only catch of the storage campaign): Provider produced inconsistent result after apply: .kms_key_id was "<key-id>", now "arn:aws:kms:..." — the L2 passed kmsKey.keyId (upstream-faithful; CFN's KmsKeyId accepts id-or-ARN so upstream never noticed), but AWS stores/returns the ARN and Terraform's read-back rejects the mismatch. Every harness retry burned a full cache create (~4 min each). Fixed to keyArn with a regression test; post-fix apply succeeded first attempt. Orphan sweep after the failed run confirmed zero stray caches/users/groups.

Run 1 was a fixture typo (referenced a nonexistent userGroupId — the alpha's surface is userGroupName); failed at plan, zero AWS resources.