(rds): isFromLegacyInstanceProps migration flag not working

### Describe the bug

When using the isFromLegacyInstanceProps to [migrate my old RDS instance properties from instanceProps](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds-readme.html#migrating-from-instanceprops) to the new method using `reader` and `writer` params, is still flagging my instances for recreation.

This would cause my instances to be recreated, and I am curious if this would bring downtime and possibly even get rid of my automated backups.

### Expected Behavior

I would except the output of the cdk diff step against my 'test' AWS account to be:

```
Stack test-rds-stack (rds-stack)
There were no differences
```

### Current Behavior

The current output of cdk diff against my 'test' AWS account using the migration property is:

```
Stack test-rds-stack (rds-stack)
Resources
[~] AWS::RDS::DBInstance rds-cluster/Instance1 rdsclusterInstance19743D359 replace
└─ [-] DBInstanceIdentifier (requires replacement)
└─ rds-clusterinstance1
[~] AWS::RDS::DBInstance rds-cluster/Instance2 rdsclusterInstance2CF41B1E4 replace
└─ [-] DBInstanceIdentifier (requires replacement)
└─ rds-clusterinstance2
```

### Reproduction Steps

Old CDK code used to deploy RDS currently on AWS test environment:
```typescript
private buildRdsCluster(): DatabaseCluster {
const rdsCluster = new DatabaseCluster(
this,
RdsUtils.RDS_CLUSTER,
{
clusterIdentifier: RdsUtils.RDS_CLUSTER,
engine: DatabaseClusterEngine.auroraPostgres(
{
version: AuroraPostgresEngineVersion.VER_14_6,
}
),
port: RdsUtils.RDS_PORT,
credentials: Credentials.fromSecret(this.rdsPostgresSecret),
storageEncrypted: true,
instanceProps: {
instanceType: InstanceType.of(InstanceClass.T3, InstanceSize.MEDIUM),
vpcSubnets: {
subnetType: SubnetType.PRIVATE_ISOLATED,
},
vpc: this.vpc,
securityGroups: [
this.rdsSecurityGroup,
],
},
backup: {
preferredWindow: '00:00-01:00',
retention: Duration.days(
this.props.isProduction ? 30 : 7
),
},
preferredMaintenanceWindow: 'Wed:01:00-Wed:02:00',
removalPolicy: RemovalPolicy.RETAIN,
}
);
new CfnOutput(
this,
`${RdsUtils.RDS_CLUSTER_ENDPOINT}-output`,
{
exportName: RdsUtils.getRdsClusterEndpointExportName(),
description: 'The RDS cluster endpoint',
value: `${rdsCluster.clusterEndpoint.socketAddress}`,
}
);
return rdsCluster;
}
```

New CDK code used to do migration with no functional changes and the migration property:
```typescript
private buildRdsCluster(): DatabaseCluster {
const instanceProps: ProvisionedClusterInstanceProps = {
instanceType: InstanceType.of(InstanceClass.T3, InstanceSize.MEDIUM),
isFromLegacyInstanceProps: true,
};

const rdsCluster = new DatabaseCluster(this, RdsUtils.RDS_CLUSTER, {
vpc: this.vpc,
securityGroups: [this.rdsSecurityGroup],
vpcSubnets: { subnetType: SubnetType.PRIVATE_ISOLATED },
clusterIdentifier: RdsUtils.RDS_CLUSTER,
engine: DatabaseClusterEngine.auroraPostgres({
version: AuroraPostgresEngineVersion.VER_14_6,
}),
port: RdsUtils.RDS_PORT,
credentials: Credentials.fromSecret(this.rdsPostgresSecret),
storageEncrypted: true,
writer: ClusterInstance.provisioned("Instance1", instanceProps),
readers: [ClusterInstance.provisioned("Instance2", instanceProps)],
backup: {
preferredWindow: "00:00-01:00",
retention: Duration.days(this.props.isProduction ? 30 : 7),
},
preferredMaintenanceWindow: "Wed:01:00-Wed:02:00",
removalPolicy: RemovalPolicy.RETAIN,
});
new CfnOutput(this, `${RdsUtils.RDS_CLUSTER_ENDPOINT}-output`, {
exportName: RdsUtils.getRdsClusterEndpointExportName(),
description: "The RDS cluster endpoint",
value: `${rdsCluster.clusterEndpoint.socketAddress}`,
});
return rdsCluster;
}
```

### Possible Solution

Using the method described in https://github.com/aws/aws-cdk/issues/25942 this problem can be solved. However in a non-ideal way.

You can directly specify an `instanceIdentifier` on both the reader and writer. However this creates a problem when deploying on multiple environments, the identifier of the reader and writer might differ on different environments due to a failover happening.

Doing this however, will cause `cdk diff` to report what we want:
```
Stack test-rds-stack (rds-stack)
There were no differences
```

Example:
```typescript
const rdsCluster = new DatabaseCluster(this, RdsUtils.RDS_CLUSTER, {
vpc: this.vpc,
securityGroups: [this.rdsSecurityGroup],
vpcSubnets: { subnetType: SubnetType.PRIVATE_ISOLATED },
clusterIdentifier: RdsUtils.RDS_CLUSTER,
engine: DatabaseClusterEngine.auroraPostgres({
version: AuroraPostgresEngineVersion.VER_14_6,
}),
port: RdsUtils.RDS_PORT,
credentials: Credentials.fromSecret(this.rdsPostgresSecret),
storageEncrypted: true,
writer: ClusterInstance.provisioned("Instance1", {
...instanceProps,
instanceIdentifier: "rds-clusterinstance1",
}),
readers: [
ClusterInstance.provisioned("Instance2", {
...instanceProps,
instanceIdentifier: "rds-clusterinstance2",
}),
],
backup: {
preferredWindow: "00:00-01:00",
retention: Duration.days(this.props.isProduction ? 30 : 7),
},
preferredMaintenanceWindow: "Wed:01:00-Wed:02:00",
removalPolicy: RemovalPolicy.RETAIN,
});
```

### Additional Information/Context

Also responded on https://github.com/aws/aws-cdk/discussions/25900

### CDK CLI Version

2.93.0 (build 724bd01)

### Framework Version

_No response_

### Node.js Version

v18.16.0

### OS

MacOs

### Language

Typescript

### Language Version

5.2.2

### Other information

Also replied on: https://github.com/aws/aws-cdk/discussions/25900

Start by reproducing the TypeScript DatabaseCluster migration from instanceProps to writer/readers with isFromLegacyInstanceProps and compare the synthesized cdk diff. Trace how the migration flag determines DBInstanceIdentifier values, then add a regression test covering Instance1 and Instance2. Done means the migration produces no DBInstanceIdentifier replacement without requiring environment-specific instanceIdentifier values.

Written by the indexing model from the issue text.