aws-ecs: support high-resolution (20s) service metrics for faster service auto scaling

### Describe the feature

Add native CDK support for Amazon ECS [high-resolution (20-second) service metrics for faster service auto scaling](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ecs-faster-autoscaling/) (announced June 2026). This spans two modules:

1. **`aws-ecs`** — expose the new ECS service-level `Monitoring` configuration (`MetricConfigurations` with `ResolutionSeconds: 20` for `CPUUtilization` / `MemoryUtilization`) on `BaseService` / `FargateService` / `Ec2Service` (and in the typed L1 `CfnService` props).
2. **`aws-applicationautoscaling`** — add the high-resolution predefined metric enum values `ECSServiceAverageCPUUtilizationHighResolution` and `ECSServiceAverageMemoryUtilizationHighResolution` to `PredefinedMetric`, analogous to the SageMaker high-resolution values added in #31113.

### Use Case

With the default 60-second ECS metrics, the detection phase dominates scale-out latency (≈5–6 minutes from a load increase to a new task being provisioned, in our load tests). The new 20-second high-resolution metrics cut detection time dramatically.

Today, CDK users must hand-write CloudFormation escape hatches for **both** the service `Monitoring` config and the high-resolution scaling-policy metric type, because:

- `PredefinedMetric` (in `aws-applicationautoscaling`) only has `ECS_SERVICE_AVERAGE_CPU_UTILIZATION` / `ECS_SERVICE_AVERAGE_MEMORY_UTILIZATION`; the `*HighResolution` variants are missing.
- The synthesized L1 `CfnService` props do not yet include the service-level `Monitoring` field (even though CloudFormation `AWS::ECS::Service` already supports it).

This is verbose and error-prone for a feature whose whole value is faster, reliable auto scaling.

### Proposed Solution

I'd defer the exact API shape to the maintainers (the CONTRIBUTING guide notes a preference for Mixins/Facades/Traits over new L2 props for new features), but two concrete pieces:

1. **Low-risk, precedented:** add the two `PredefinedMetric` enum values (`ECSServiceAverageCPUUtilizationHighResolution`, `ECSServiceAverageMemoryUtilizationHighResolution`). This directly mirrors #31113 for SageMaker.
2. **ECS service monitoring:** surface the `Monitoring` configuration on the service construct (and/or the typed `CfnService` props) so users can opt CPU/Memory into 20-second resolution, ideally wired so `scaleOnCpuUtilization` / `scaleOnMemoryUtilization` can select the high-resolution predefined metric.

Workaround we use today (escape hatch):

```ts
import type { CfnScalingPolicy } from "aws-cdk-lib/aws-applicationautoscaling"
import type { CfnService } from "aws-cdk-lib/aws-ecs"

// 1) Enable 20s service metrics
const cfnService = service.node.defaultChild as CfnService
cfnService.addPropertyOverride("Monitoring", {
MetricConfigurations: [
{ MetricNames: ["CPUUtilization", "MemoryUtilization"], ResolutionSeconds: 20 },
],
})

// 2) Build the L2 target-tracking policies as usual...
const scaling = service.autoScaleTaskCount({ minCapacity: 1, maxCapacity: 5 })
scaling.scaleOnCpuUtilization("CpuScaling", { targetUtilizationPercent: 60 })
scaling.scaleOnMemoryUtilization("MemoryScaling", { targetUtilizationPercent: 60 })

// 3) ...then override the synthesized policy metric type to the HighResolution variant
const useHighResolutionMetric = (policyId: string, predefinedMetricType: string): void => {
const policy = scaling.node
.findChild("Target")
.node.findChild(policyId)
.node.defaultChild as CfnScalingPolicy
policy.addPropertyOverride(
"TargetTrackingScalingPolicyConfiguration.PredefinedMetricSpecification.PredefinedMetricType",
predefinedMetricType,
)
}
useHighResolutionMetric("CpuScaling", "ECSServiceAverageCPUUtilizationHighResolution")
useHighResolutionMetric("MemoryScaling", "ECSServiceAverageMemoryUtilizationHighResolution")
```

### Other Information

- Announcement: https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ecs-faster-autoscaling/
- Blog: https://aws.amazon.com/blogs/aws/amazon-ecs-introduces-new-high-resolution-metrics-for-faster-service-auto-scaling/
- ECS docs (predefined metric names + Monitoring config): https://docs.aws.amazon.com/AmazonECS/latest/developerguide/target-tracking-faster-auto-scaling.html
- CloudFormation `AWS::ECS::Service` `Monitoring` (type `MonitoringConfiguration`, `MetricConfigurations` 1–2 entries) is already supported: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-monitoringconfiguration.html
- Precedent for the enum addition: #31113 (SageMaker high-resolution predefined metric).
- **Two-step constraint for existing services:** per the ECS docs, updating an *existing* service is a two-step process — first update the monitoring resolution (which triggers a deployment), then, after tasks emit at 20-second resolution, attach the high-resolution scaling policy. A new service can set both at creation. Native CDK support should account for / document this ordering.
- Reproduced on `aws-cdk-lib` 2.257.0 and 2.258.1; neither exposes the enum values or the service `Monitoring` field.

Start in the aws-applicationautoscaling PredefinedMetric definition and compare the SageMaker high-resolution additions from #31113. Then inspect the aws-ecs BaseService/FargateService/Ec2Service APIs and typed CfnService props for the Monitoring configuration. Done means native support covers the two ECS high-resolution metric values and service monitoring, with the existing-service update ordering accounted for or documented.

Written by the indexing model from the issue text.