feat(sources): update documentation

[aws-cdk-automation]

⚠️ This Pull Request updates daily and will overwrite all manual changes pushed to the branch

Updates the documentation source from upstream. See details in workflow run.

---

Automatically created by projen via the "update-source-documentation" workflow

[github-actions]

To work on this Pull Request, please create a new branch and PR. This prevents your work from being deleted by the automation.

Run the following commands inside the repo:

gh co 1446
git switch -c fix-pr-1446 && git push -u origin HEAD
gh pr create -t "fix: PR #1446" --body "Fixes https://github.com/cdklabs/awscdk-service-spec/pull/1446"

[github-actions]

@aws-cdk/aws-service-spec: Model database diff detected

├[~] service aws-applicationsignals
│ └ resources
│    └[~] resource AWS::ApplicationSignals::ServiceLevelObjective
│      └  - documentation: Creates or updates a service level objective (SLO), which can help you ensure that your critical business operations are meeting customer expectations. Use SLOs to set and track specific target levels for the reliability and availability of your applications and services. SLOs use service level indicators (SLIs) to calculate whether the application is performing at the level that you want.
│         Create an SLO to set a target for a service or operation’s availability or latency. CloudWatch measures this target frequently you can find whether it has been breached.
│         The target performance quality that is defined for an SLO is the *attainment goal* . An attainment goal is the percentage of time or requests that the SLI is expected to meet the threshold over each time interval. For example, an attainment goal of 99.9% means that within your interval, you are targeting 99.9% of the periods to be in healthy state.
│         When you create an SLO, you specify whether it is a *period-based SLO* or a *request-based SLO* . Each type of SLO has a different way of evaluating your application's performance against its attainment goal.
│         - A *period-based SLO* uses defined *periods* of time within a specified total time interval. For each period of time, Application Signals determines whether the application met its goal. The attainment rate is calculated as the `number of good periods/number of total periods` .
│         For example, for a period-based SLO, meeting an attainment goal of 99.9% means that within your interval, your application must meet its performance goal during at least 99.9% of the time periods.
│         - A *request-based SLO* doesn't use pre-defined periods of time. Instead, the SLO measures `number of good requests/number of total requests` during the interval. At any time, you can find the ratio of good requests to total requests for the interval up to the time stamp that you specify, and measure that ratio against the goal set in your SLO.
│         After you have created an SLO, you can retrieve error budget reports for it. An *error budget* is the amount of time or amount of requests that your application can be non-compliant with the SLO's goal, and still have your application meet the goal.
│         - For a period-based SLO, the error budget starts at a number defined by the highest number of periods that can fail to meet the threshold, while still meeting the overall goal. The *remaining error budget* decreases with every failed period that is recorded. The error budget within one interval can never increase.
│         For example, an SLO with a threshold that 99.95% of requests must be completed under 2000ms every month translates to an error budget of 21.9 minutes of downtime per month.
│         - For a request-based SLO, the remaining error budget is dynamic and can increase or decrease, depending on the ratio of good requests to total requests.
│         When you call this operation, Application Signals creates the *AWSServiceRoleForCloudWatchApplicationSignals* service-linked role, if it doesn't already exist in your account. This service- linked role has the following permissions:
│         - `xray:GetServiceGraph`
│         - `logs:StartQuery`
│         - `logs:GetQueryResults`
│         - `cloudwatch:GetMetricData`
│         - `cloudwatch:ListMetrics`
│         - `tag:GetResources`
│         - `autoscaling:DescribeAutoScalingGroups`
│         You can easily set SLO targets for your applications that are discovered by Application Signals, using critical metrics such as latency and availability. You can also set SLOs against any CloudWatch metric or math expression that produces a time series.
│         You cannot change from a period-based SLO to a request-based SLO, or change from a request-based SLO to a period-based SLO.
│         For more information about SLOs, see [Service level objectives (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) .
│         + documentation: Creates or updates a service level objective (SLO), which can help you ensure that your critical business operations are meeting customer expectations. Use SLOs to set and track specific target levels for the reliability and availability of your applications and services. SLOs use service level indicators (SLIs) to calculate whether the application is performing at the level that you want.
│         Create an SLO to set a target for a service or operation’s availability or latency. CloudWatch measures this target frequently you can find whether it has been breached.
│         The target performance quality that is defined for an SLO is the *attainment goal* . An attainment goal is the percentage of time or requests that the SLI is expected to meet the threshold over each time interval. For example, an attainment goal of 99.9% means that within your interval, you are targeting 99.9% of the periods to be in healthy state.
│         When you create an SLO, you specify whether it is a *period-based SLO* or a *request-based SLO* . Each type of SLO has a different way of evaluating your application's performance against its attainment goal.
│         - A *period-based SLO* uses defined *periods* of time within a specified total time interval. For each period of time, Application Signals determines whether the application met its goal. The attainment rate is calculated as the `number of good periods/number of total periods` .
│         For example, for a period-based SLO, meeting an attainment goal of 99.9% means that within your interval, your application must meet its performance goal during at least 99.9% of the time periods.
│         - A *request-based SLO* doesn't use pre-defined periods of time. Instead, the SLO measures `number of good requests/number of total requests` during the interval. At any time, you can find the ratio of good requests to total requests for the interval up to the time stamp that you specify, and measure that ratio against the goal set in your SLO.
│         After you have created an SLO, you can retrieve error budget reports for it. An *error budget* is the amount of time or amount of requests that your application can be non-compliant with the SLO's goal, and still have your application meet the goal.
│         - For a period-based SLO, the error budget starts at a number defined by the highest number of periods that can fail to meet the threshold, while still meeting the overall goal. The *remaining error budget* decreases with every failed period that is recorded. The error budget within one interval can never increase.
│         For example, an SLO with a threshold that 99.95% of requests must be completed under 2000ms every month translates to an error budget of 21.9 minutes of downtime per month.
│         - For a request-based SLO, the remaining error budget is dynamic and can increase or decrease, depending on the ratio of good requests to total requests.
│         When you call this operation, Application Signals creates the *AWSServiceRoleForCloudWatchApplicationSignals* service-linked role, if it doesn't already exist in your account. This service- linked role has the following permissions:
│         - `xray:GetServiceGraph`
│         - `logs:StartQuery`
│         - `logs:GetQueryResults`
│         - `cloudwatch:GetMetricData`
│         - `cloudwatch:ListMetrics`
│         - `tag:GetResources`
│         - `autoscaling:DescribeAutoScalingGroups`
│         You can easily set SLO targets for your applications that are discovered by Application Signals, using critical metrics such as latency and availability. You can also set SLOs against any CloudWatch metric or math expression that produces a time series.
│         > You can't create an SLO for a service operation that was discovered by Application Signals until after that operation has reported standard metrics to Application Signals. 
│         You cannot change from a period-based SLO to a request-based SLO, or change from a request-based SLO to a period-based SLO.
│         For more information about SLOs, see [Service level objectives (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) .
├[~] service aws-autoscaling
│ └ resources
│    └[~] resource AWS::AutoScaling::AutoScalingGroup
│      ├ properties
│      │  └ AvailabilityZoneImpairmentPolicy: (documentation changed)
│      └ types
│         └[~] type AvailabilityZoneImpairmentPolicy
│           ├  - documentation: undefined
│           │  + documentation: Describes an Availability Zone impairment policy.
│           └ properties
│              ├ ImpairedZoneHealthCheckBehavior: (documentation changed)
│              └ ZonalShiftEnabled: (documentation changed)
├[~] service aws-dynamodb
│ └ resources
│    ├[~] resource AWS::DynamoDB::GlobalTable
│    │ ├ properties
│    │ │  └ WriteOnDemandThroughputSettings: (documentation changed)
│    │ └ types
│    │    ├[~] type GlobalSecondaryIndex
│    │    │ └ properties
│    │    │    └ WriteOnDemandThroughputSettings: (documentation changed)
│    │    ├[~] type ReadOnDemandThroughputSettings
│    │    │ └  - documentation: Sets the read request settings for a replica table or a replica global secondary index. You must specify this setting if you set the `BillingMode` to `PAY_PER_REQUEST` .
│    │    │    + documentation: Sets the read request settings for a replica table or a replica global secondary index. You can only specify this setting if your resource uses the `PAY_PER_REQUEST` `BillingMode` .
│    │    ├[~] type ReplicaGlobalSecondaryIndexSpecification
│    │    │ └ properties
│    │    │    └ ReadOnDemandThroughputSettings: (documentation changed)
│    │    └[~] type WriteOnDemandThroughputSettings
│    │      └  - documentation: Sets the write request settings for a global table or a global secondary index. You must specify this setting if you set the `BillingMode` to `PAY_PER_REQUEST` .
│    │         + documentation: Sets the write request settings for a global table or a global secondary index. You can only specify this setting if your resource uses the `PAY_PER_REQUEST` `BillingMode` .
│    └[~] resource AWS::DynamoDB::Table
│      └ properties
│         └ ImportSourceSpecification: (documentation changed)
├[~] service aws-ecs
│ └ resources
│    ├[~] resource AWS::ECS::Service
│    │ ├ properties
│    │ │  ├ HealthCheckGracePeriodSeconds: (documentation changed)
│    │ │  └ VpcLatticeConfigurations: (documentation changed)
│    │ └ types
│    │    └[~] type VpcLatticeConfiguration
│    │      ├  - documentation: undefined
│    │      │  + documentation: The VPC Lattice configuration for your service that holds the information for the target group(s) Amazon ECS tasks will be registered to.
│    │      └ properties
│    │         ├ PortName: (documentation changed)
│    │         ├ RoleArn: (documentation changed)
│    │         └ TargetGroupArn: (documentation changed)
│    └[~] resource AWS::ECS::TaskDefinition
│      └ types
│         └[~] type PortMapping
│           └ properties
│              └ Name: (documentation changed)
├[~] service aws-iotsitewise
│ └ resources
│    └[~] resource AWS::IoTSiteWise::Dashboard
│      └ properties
│         └ DashboardDefinition: (documentation changed)
└[~] service aws-wisdom
  └ resources
     ├[~] resource AWS::Wisdom::AIAgentVersion
     │ └ attributes
     │    ├ AIAgentArn: (documentation changed)
     │    └ AssistantArn: (documentation changed)
     ├[~] resource AWS::Wisdom::AIPromptVersion
     │ └ attributes
     │    └ AssistantArn: (documentation changed)
     └[~] resource AWS::Wisdom::Assistant
       ├  - documentation: Creates an Amazon Q in Connect assistant.
       │  + documentation: Specifies an Amazon Connect Wisdom assistant.
       ├ properties
       │  ├ Description: (documentation changed)
       │  ├ Name: (documentation changed)
       │  └ ServerSideEncryptionConfiguration: (documentation changed)
       └ attributes
          └ AssistantId: (documentation changed)