[AWS::DMS::Endpoint] - [Coverage] - PostgreSqlSettings missing AuthenticationMethod and ServiceAccessRoleArn: RDS IAM authentication unreachable CloudFormation

### Name of the resource

AWS::DMS::Endpoint

### Resource name

_No response_

### Description

## Description

DMS supports IAM database authentication on RDS and Aurora endpoints from replication engine version 3.6.1, documented at [Using IAM authentication for Amazon RDS endpoint in AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Endpoints.Creating.IAMRDS.html). For PostgreSQL this is configured with two settings inside `PostgreSqlSettings`: `AuthenticationMethod: iam` and `ServiceAccessRoleArn`.

Both are supported by the service:

```
$ aws dms describe-endpoint-settings --engine-name postgres --region eu-west-1
...
{ "Name": "AuthenticationMethod", "Type": "enum", "EnumValues": ["password", "iam"], "Sensitive": false }
{ "Name": "ServiceAccessRoleArn", ... }
```

Neither appears in the CloudFormation resource reference for [`AWS::DMS::Endpoint PostgreSqlSettings`](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-dms-endpoint-postgresqlsettings.html), which lists 16 properties, and neither is accepted by the resource. Both are rejected at changeset creation by `AWS::EarlyValidation::PropertyValidation`, independently of one another.

The effect is that CloudFormation users cannot use IAM authentication for DMS at all. For a source endpoint against a production database that means provisioning and rotating a credential which the DMS user guide requires to hold `rds_superuser`, where IAM authentication would need no stored credential.

This also blocks the CDK: `CfnEndpoint.PostgreSqlSettingsProperty` carries neither field in `aws-cdk-lib`, since L1 constructs are generated from the resource schema. `addPropertyOverride` does not help, because the rejection is schema validation rather than pass-through.

## Reproduction

Three templates differing only in these two properties. All other properties are held constant.

| `AuthenticationMethod` | `ServiceAccessRoleArn` | Changeset result |
| ---------------------- | ---------------------- | ---------------- |
| absent | present | FAILED |
| present | absent | FAILED |
| absent | absent | CREATE_COMPLETE |

Minimal failing template (`ServerName` is deliberately unreachable; endpoint creation does not test connectivity):

```yaml
AWSTemplateFormatVersion: "2010-09-09"
Resources:
DmsAuthRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: dms.amazonaws.com
Action: sts:AssumeRole
SourceEndpoint:
Type: AWS::DMS::Endpoint
Properties:
EndpointIdentifier: dms-iam-probe
EndpointType: source
EngineName: postgres
DatabaseName: mydb
Username: myuser
ServerName: probe.invalid
Port: 5432
SslMode: require
PostgreSqlSettings:
MapBooleanAsBoolean: true
AuthenticationMethod: iam
ServiceAccessRoleArn: !GetAtt DmsAuthRole.Arn
```

```
$ aws cloudformation deploy --template-file probe.yaml --stack-name dms-iam-probe --capabilities CAPABILITY_IAM --region eu-west-1

Failed to create the changeset: Waiter ChangeSetCreateComplete failed: Waiter encountered a
terminal failure state: For expression "Status" we matched expected path: "FAILED"
Status: FAILED. Reason: The following hook(s)/validation failed:
[AWS::EarlyValidation::PropertyValidation]
```

Removing both properties and changing nothing else produces `CREATE_COMPLETE`.

## Secondary point on diagnosability

The early validation failure names no property. `aws cloudformation list-hook-results --target-type CHANGE_SET --target-id ` returns an empty `HookResults` array, `describe-change-set` repeats the same generic string, and `describe-stack-events` shows only `REVIEW_IN_PROGRESS`. The message advises using the DescribeEvents API for detail, and no detail is available there. Isolating the offending property required deploying variants differing by one field. Surfacing the rejected property name in the failure reason would have made that unnecessary.

## Related

[#1781](https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/1781) asks a similar question for `MicrosoftSqlServerSettings`. The answer there is that the `Settings` blocks accept the settings listed in the DMS API reference and that the CloudFormation documentation lags. That does not hold here: the settings are in the API reference and the resource rejects them.

## Other details

- Region tested: `eu-west-1`
- The same two settings work through `aws dms create-endpoint` and `aws dms modify-endpoint`, so this is a CloudFormation resource gap rather than a service limitation.

### Other Details

_No response_

Start with the AWS::DMS::Endpoint PostgreSqlSettings resource reference and compare it with `aws dms describe-endpoint-settings --engine-name postgres`. Trace how the CloudFormation schema handles AuthenticationMethod and ServiceAccessRoleArn, then verify the minimal changeset template succeeds and the two properties are represented in the resource reference.

Written by the indexing model from the issue text.