[AWS::LakeFormation::PrincipalPermissions] - [BUG] - Inconsistent tracking of status of permissions, when multiple resources are created at the same time

### Name of the resource

AWS::LakeFormation::PrincipalPermissions

### Resource Name

_No response_

### Issue Description

When creating multiple permissions at the same time, it seems that CloudFormation is not able to properly track individual resources, which results in failures during creation. It seems that the resource tracking is deleted/taken out of memory in some way, as an exception occurs, stating that the resource already exists.

### Expected Behavior

Multiple principle permissions are created, at the same time

### Observed Behavior

Some permissions are created in AWS and tracked in CloudFormation, whilst others are created in AWS, but are not detected from CloudFormation post creation. This results in the following error

> Stack | 11:31:03 | CREATE_FAILED | AWS::LakeFormation::PrincipalPermissions | Stack-resource (StackResource) Resource handler returned message: "Resource of type 'AWS::LakeFormation::PrincipalPermissions' with identifier 'StackResource' already exists." (RequestToken: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, HandlerErrorCode: **AlreadyExists**)

Notice how the error code states the resource already exists?

### Test Cases

Drift detection only detects permissions upon successful deployment

Testing using multiple permissions being created at the same time - FAILS

Using the same stack, adding a dependency for each lakeformation permission, depending on the previous permission in the list - PASSES
```ts
declare const lakeformationPermissions: lakeformationCfn.CfnPrincipalPermissions;

for (let i = 1; i < lakeformationPermissions.length; i++) {
lakeformationPermissions[i].addDependency(
lakeformationPermissions[i - 1]
);
}
```
The above test is written in CDK, but it uses the L1 Construct, which is a 1:1 match with CloudFormation

### Other Details

The resource is created in AWS, but CloudFormation is not able to detect that the permission had been created via the CloudFormation stack. So CloudFormation would create the permission in AWS (alongside a bunch of others), have some form of memory leak, and state that the resource is already created