Proposal: AWS CDK reference deployment for buzz-relay (ECS Fargate, no Kubernetes)

## What

An AWS CDK (TypeScript) app that stands up `buzz-relay` on AWS-native services with no Kubernetes dependency — the AWS-shop counterpart to `deploy/charts/buzz`. Two stacks:

- **`BuzzRelayData`** — VPC lookup + security groups, RDS Postgres (Multi-AZ), ElastiCache Redis (2-node, TLS), S3 media bucket, generated Secrets Manager secrets (relay identity, connection strings). Deployed once, redeployed rarely.
- **`BuzzRelayService`** — ECS Fargate service/task, ALB, Route53/ACM. Redeployed freely. Depends on `BuzzRelayData` via `addStackDependency`, but a service-stack-only `cdk deploy`/`cdk destroy` can never touch RDS/ElastiCache/S3/secrets.

The two-stack split exists because we hit `RemovalPolicy.RETAIN` not surviving a same-stack rollback in testing — a failed compute-layer deploy repeatedly destroyed and recreated RDS when data and compute lived in one stack.

BYO-VPC only (never creates a VPC), production-profile only (no quickstart/eval tier — CDK apps are consumed as source, not published), relay-only scope for v1 (device pairing via `buzz-pair-relay` is included; `buzz-push-gateway`/APNs is not).

## Why

We're an AWS + GitHub Actions + CDK/Fargate shop with no EKS and no GitOps controller (ArgoCD/Flux). `deploy/charts/buzz` is designed for Kubernetes/GitOps, which would mean standing up a whole new operational model (EKS + ArgoCD or Flux) just to run one relay. A CDK app deploys the same way everything else we run does.

We also noticed #5211 (Helm chart can't select the AWS credential chain for S3 — IRSA/Pod Identity unreachable), which suggests AWS-native operators hitting friction with the Kubernetes path isn't unique to us.

## Ask

Before we invest further polish/tests here: is this a direction the maintainers would merge? Specifically:

1. Is a second, AWS-specific non-Kubernetes deployment path in scope for this repo, alongside the Helm chart?
2. Any concerns about ongoing maintenance burden (e.g. env-var surface has to be hand-mirrored between `deploy/charts/buzz/values.yaml` and a CDK equivalent)?
3. Any objection to the two-stack design, or to CDK/TypeScript as the tool of choice here?

Happy to open the PR for review if this is a direction you'd take.

Start by reviewing deploy/charts/buzz and its values.yaml, then read the concerns in #5211 about AWS credentials. First get maintainer agreement on whether an AWS-specific CDK path belongs in the repository and whether the two-stack design is acceptable. Done means an agreed scope and an approved implementation plan before opening the larger PR.

Written by the indexing model from the issue text.