(langfuse-deploy) Langfuse deployment failing in ap-northeast-2 Seoul

As identified by @raphael-shin [in this PR](https://github.com/aws-samples/deploy-langfuse-on-ecs-with-fargate/pull/25#issuecomment-3002444568), deployment of the Langfuse CDK solution fails in Seoul because it tries to use an Availability Zone that isn't [supported by CloudFront VPC Origins](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html#vpc-origins-supported-regions).

Unfortunately though, by my testing the original proposed fix doesn't work properly: `stack.availabilityZones` returns AZ **names** (e.g. `ap-northeast-2a`), whereas support is defined by AZ ID (excluding `apne2-az1`).

As detailed [here](https://docs.aws.amazon.com/global-infrastructure/latest/regions/az-ids.html), 9 older AWS Regions map AZ IDs to different names per AWS Account - while all newer Regions have a global 1:1 ID-Name mapping. We can't really ignore this complexity because 3 (but not all) of the CloudFront-restricted regions are in that older list (Virginia, California, Tokyo).

As a result we're probably also at risk of intermittent deployment failures also in California, Tokyo, and (less likely because of the higher AZs-to-unsupported-AZs ratio) Virginia - depending on the target AWS Account's internal AZ ID-name mapping, assuming CDK defaults to AZs 'a' and 'b'. Seoul I expect is probably always failing since it's `az1` that's unsupported, presumably the deterministic mapping names that 'a', and presumably CDK `Vpc`'s default 2-AZ selection is 'a' and 'b'.