LPX-263: ElastiCache (Valkey) cache + manifest-driven session store

[stevethomas]

Hey, I made a thing! 🥳

LPX-263

What problems are you solving?

Fargate apps had no shared cache or session store — they fell back to Laravel's default drivers on the ephemeral, per-task filesystem, which breaks the moment an app runs more than one task or needs state to survive a restart (disconnected caches, sessions lost across rolling deploys, unshared rate-limiters/locks). This ships the full "cache + session store":

• aws.cache → a shared, env-scoped Valkey (ElastiCache) cache: a single-node replication group (cache.t4g.micro, allkeys-lru, at-rest encryption), a cache subnet group across the VPC subnets, and a security group allowing 6379 only from the Fargate task SG. Bootstrapped from sync:app like the RDS SG. Injects CACHE_STORE=redis + REDIS_HOST / REDIS_PORT / REDIS_PREFIX (only if your .env doesn't set them).
• session.driver → a manifest-driven session backend. YOLO injects SESSION_DRIVER and provisions only what each driver needs: dynamodb gets a per-app DynamoDB table (on-demand, TTL on expires_at) + a task-role grant + DYNAMODB_CACHE_TABLE; redis reuses the cache (requires aws.cache); database / cookie / file are app-managed.
• Refactor (polish): the shared "authorise <port> from the task SG" logic is extracted into an AuthorisesTaskIngress trait (now used by both the RDS SG and cache SG steps), and the ElastiCache describe-and-match lookups collapse into one helper.

Is there anything the reviewer needs to know to deploy this?

• Fully opt-in & backwards-compatible — apps without aws.cache / session.driver are unchanged. The new steps return SKIPPED; no new resources, no env-var changes for existing apps.
• First sync:app with aws.cache blocks ~5 min while the replication group reaches available (a one-time waitUntil in create()); subsequent syncs are no-ops.
• EcsTaskPolicy gains a DynamoDB statement (scoped to yolo-{env}-* tables). It reconciles onto existing task roles via the existing synchroniseDocument() (new default policy version), so the next sync:environment will show a task-policy change even for apps not using DynamoDB — a harmless capability grant.
• dynamodb sessions require the app to have aws/aws-sdk-php installed.
• Single node, no HA replica, no autoscaling is a deliberate design choice (see the issue thread). Invalid session.driver values — and redis without aws.cache — hard-fail at manifest-integrity time. Cache loss repopulates from source; session durability is the dynamodb driver's job. In-transit TLS + AUTH hardening is tracked as a follow-up.
• No live AWS was touched. Validation is the mocked Pest suite (456 green), with phpstan + pint clean and the VitePress docs build clean.

🤖 Generated with Claude Code