AWS::DMS::ReplicationTask - [BUG] - False-positive drift on ReplicationTaskIdentifier (service lowercases the identifier)

### Name of the resource

AWS::DMS::ReplicationTask

### Resource Name

_No response_

### Issue Description

Drift detection reports a false-positive drift on the `ReplicationTaskIdentifier` property of `AWS::DMS::ReplicationTask`. If the template sets the identifier with any upper-case letters, DMS stores it in lower case on create. Drift detection then compares the mixed-case template value against the lower-cased value from the service and reports drift, although nothing actually changed after deployment.

### Expected Behavior

The stack stays `IN_SYNC`. Drift detection should take the DMS lower-casing of `ReplicationTaskIdentifier` into account (for example via a property transform in the resource schema), so a mixed-case template value is not reported as drift.

### Observed Behavior

The identifier is written in mixed case in the template, DMS stores it in lower case, and drift detection flags `/ReplicationTaskIdentifier` as changed. Drift output from a freshly deployed stack, no manual changes (only the relevant PropertyDifference is shown):

```json
{
"LogicalResourceId": "ReplicationTask",
"ResourceType": "AWS::DMS::ReplicationTask",
"PropertyDifferences": [
{
"PropertyPath": "/ReplicationTaskIdentifier",
"ExpectedValue": "DMS-Drift-Repro-Task-01",
"ActualValue": "dms-drift-repro-task-01",
"DifferenceType": "NOT_EQUAL"
}
],
"StackResourceDriftStatus": "MODIFIED"
}
```

### Test Cases

This template is self-contained: it creates its own VPC and subnets, the smallest replication instance, and two dummy mysql endpoints with placeholder hosts (only created, never connected to). The task is never started and no database is involved. Pick a `ReplicationInstanceClass` that `aws dms describe-orderable-replication-instances` returns in your region.

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Repro - false-positive drift on DMS ReplicationTaskIdentifier (service lowercases the identifier)

Parameters:
ReplicationInstanceClass:
Type: String
Default: dms.t3.small

Resources:
Vpc:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16

Subnet1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref Vpc
CidrBlock: 10.0.1.0/24
AvailabilityZone: !Select [0, !GetAZs '']

Subnet2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref Vpc
CidrBlock: 10.0.2.0/24
AvailabilityZone: !Select [1, !GetAZs '']

ReplicationSubnetGroup:
Type: AWS::DMS::ReplicationSubnetGroup
Properties:
ReplicationSubnetGroupIdentifier: dms-drift-repro-task-subnetgroup
ReplicationSubnetGroupDescription: Repro subnet group for task drift
SubnetIds:
- !Ref Subnet1
- !Ref Subnet2

ReplicationInstance:
Type: AWS::DMS::ReplicationInstance
Properties:
ReplicationInstanceClass: !Ref ReplicationInstanceClass
ReplicationSubnetGroupIdentifier: !Ref ReplicationSubnetGroup
PubliclyAccessible: false
AllocatedStorage: 5

SourceEndpoint:
Type: AWS::DMS::Endpoint
Properties:
EndpointType: source
EngineName: mysql
ServerName: source.example.invalid
Port: 3306
Username: repro
Password: ReproPlaceholder123

TargetEndpoint:
Type: AWS::DMS::Endpoint
Properties:
EndpointType: target
EngineName: mysql
ServerName: target.example.invalid
Port: 3306
Username: repro
Password: ReproPlaceholder123

ReplicationTask:
Type: AWS::DMS::ReplicationTask
Properties:
ReplicationTaskIdentifier: DMS-Drift-Repro-Task-01
MigrationType: full-load
ReplicationInstanceArn: !Ref ReplicationInstance
SourceEndpointArn: !Ref SourceEndpoint
TargetEndpointArn: !Ref TargetEndpoint
TableMappings: >-
{"rules":[{"rule-type":"selection","rule-id":"1","rule-name":"r1","object-locator":{"schema-name":"%","table-name":"%"},"rule-action":"include"}]}
ReplicationTaskSettings: >-
{"TargetMetadata":{"SupportLobs":true,"FullLobMode":false,"LobChunkSize":64},"FullLoadSettings":{"TargetTablePrepMode":"DO_NOTHING"}}
```

Steps:

1. Deploy the stack and wait for `CREATE_COMPLETE` (the task takes a few minutes to reach the `ready` state).
2. Run drift detection (Console: Stack actions -> Detect drift, or CLI `detect-stack-drift`).
3. Look at the drift details for the ReplicationTask.

The stack goes to `DRIFTED` and `ReplicationTask` shows `MODIFIED` on `/ReplicationTaskIdentifier`, with the expected value in mixed case and the actual value in lower case.

### Other Details

Companion issue for the same DMS identifier lower-casing behaviour on a different resource type (`AWS::DMS::ReplicationSubnetGroup`): #2560.

AWS Support Case: 178853082300312

Use the supplied CloudFormation template to create the AWS::DMS::ReplicationTask, then run detect-stack-drift and inspect the ReplicationTask drift details. Investigate the resource schema's handling of ReplicationTaskIdentifier; done means mixed-case template values no longer produce a false-positive drift and the stack remains IN_SYNC.

Written by the indexing model from the issue text.