CloudFormation should wait for SageMaker to clean up ENIs when deleting SageMaker endpoints hosting VPC-connected models

### Name of the resource

AWS::SageMaker::Endpoint

### Resource name

_No response_

### Description

When SageMaker provisions EC2 instances to deploy a customer's `AWS::SageMaker::Endpoint` resource for VPC-connected models, SageMaker creates Elastic Network Interfaces (ENIs) in the customer's account outside of the associated CloudFormation stack. When deleting a stack, CloudFormation will successfully delete the endpoint resource followed by the model before failing to delete the associated security group(s) and subnet(s). Unfortunately, as there are ENIs associated with these networking resources, stack deletion will fail after 15 minutes with errors like:

```
resource sg- has a dependent object (Service: AmazonEC2; Status Code: 400; Error Code: DependencyViolation; Request ID: ; Proxy: null)
```
```
Resource handler returned message: "The subnet 'subnet-' has dependencies and cannot be deleted. (Service: Ec2, Status Code: 400, Request ID: , Extended Request ID: null)" (RequestToken: , HandlerErrorCode: InvalidRequest)
```

Just as [CloudFormation waits for Lambda-created ENIs to be cleaned up on function deletion](https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/392), shouldn't CloudFormation do the same with SageMaker?

### Other Details

_No response_

Start by reviewing the AWS::SageMaker::Endpoint deletion flow described in the issue and comparing it with the linked Lambda ENI cleanup behavior. Done means CloudFormation waits for SageMaker-created ENIs to be removed before deleting dependent security groups and subnets, preventing the reported dependency errors.

Written by the indexing model from the issue text.