aws-cognito: Custom attributes cannot have the same name as standard attributes

### Describe the bug

It is currently not possible to correctly create a Cognito user pool with custom attributes that share the same name as one of the standard attributes. It does **not** result in an error from CloudFormation. However, the resulting user pool is missing the custom attributes when they already exist as standard attributes which leads to errors when trying to create an app client and giving it permissions to alter those missing custom attributes.

We already have an existing user pool where we were able to add custom attributes with the same name. However when trying to create a completely new user pool with our configuration this now fails.

### Regression Issue

- [X] Select this option if this issue appears to be a regression.

### Last Known Working CDK Version

_No response_

### Expected Behavior

The custom attribute despite having same name as the equivalent standard attribute is created.

### Current Behavior

The custom attribute with the same name is silently dropped.

### Reproduction Steps

```typescript
export class CognitoTestStack extends Stack {
constructor(scope: Construct, id: string, props: StackProps) {
super(scope, id, props);

new UserPool(this, 'UserPool', {
userPoolName: 'sample-cdk-test',
customAttributes: { address: new StringAttribute({ mutable: true }) },
});
}
}
```

And the resulting attributes are:


note the **missing** `custom:address` attribute.

### Possible Solution

_No response_

### Additional Information/Context

_No response_

### CDK CLI Version

2.158.0 (build 4b8714d)

### Framework Version

_No response_

### Node.js Version

v20.14.0

### OS

macOS 14.7 (23H124)

### Language

TypeScript

### Language Version

TypeScript (5.6.2)

### Other information

_No response_

Start with the TypeScript UserPool reproduction using customAttributes and the StringAttribute for address. Inspect the synthesized or deployed Cognito user pool and app-client configuration to trace where custom:address is dropped. Done means a new pool retains the custom attribute despite the matching standard attribute and permits the documented app-client permissions.

Written by the indexing model from the issue text.