(aws-lambda): AWS::SNS::TopicPolicy is created unexpectedly

### Describe the bug

If no custom role is defined in lambda, no AWS::SNS::TopicPolicy will be created in the CloudFormation stack resources, and the SNS topic will have a default access policy.

However, if a custom role with sns:Publish permission is created manually and explicitly defined in the Lambda CDK script, an AWS::SNS::TopicPolicy will be created.

My question is: why is the AWS::SNS::TopicPolicy created in this case?

### Regression Issue

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

### Last Known Working CDK Version

_No response_

### Expected Behavior

If a custom role is defined explicitly, no `AWS::SNS::TopicPolicy` will be created in the CloudFormation stack resources

### Current Behavior

If a custom role is defined explicitly, a `AWS::SNS::TopicPolicy` will be created in the CloudFormation stack resources.

### Reproduction Steps

You can run `cdk synth` to view the CloudFormation template.

When using `role: iam.Role.fromRoleArn`, the `AWS::SNS::TopicPolicy` will not appear in the CloudFormation template.

However, if you omit or comment out `role: iam.Role.fromRoleArn`, an `AWS::SNS::TopicPolicy` will be included in the CloudFormation template.

```ts
import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as destinations from 'aws-cdk-lib/aws-lambda-destinations';
import { Construct } from 'constructs';

export class LambdaWithSnsStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);

// Create an SNS topic
const failureTopic = new sns.Topic(this, 'FailureTopic', {
displayName: 'Lambda Failure Notifications',
});

// Create the Lambda function
new lambda.Function(this, 'MyFunction', {
runtime: lambda.Runtime.PYTHON_3_11,
handler: 'index.handler',
code: lambda.Code.fromAsset('lambda'), // Change 'lambda' to your function path
timeout: cdk.Duration.seconds(10),
onFailure: new destinations.SnsDestination(failureTopic),
role: iam.Role.fromRoleArn(this, "LambdaExecutionRole", 'arn:aws:iam::xxx:role/xxx-lambda-common-role', {
mutable: false
})
});
}
}

```

### Possible Solution

_No response_

### Additional Information/Context

_No response_

### CDK CLI Version

2.159.1 (build c66f4e3)

### Framework Version

_No response_

### Node.js Version

v20.12.2

### OS

MacOS 15.1

### Language

TypeScript

### Language Version

_No response_

### Other information

The default access policy of sns topic is as follow

```
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish"
],
"Resource": "arn:aws:sns:us-east-1:xxx:xxx-xxx-test-xxx-xxx",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "xxx"
}
}
}
]
}
```

If a custom role is defined explicitly, the access policy of sns topic would be

```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "0",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxx:role/xxx-xxx-lambda-common-role"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-1:xxx:xxx-xxx-xxx-xxx-xxx-xxx"
}
]
}
```

Start by running cdk synth on the supplied TypeScript stack, comparing templates with an imported role and with no explicit role. Trace the Lambda failure destination and SNS topic policy generation to determine why the synthesized AWS::SNS::TopicPolicy differs. Done means establishing whether the behavior is intended and, if not, identifying the relevant CDK behavior to correct or document.

Written by the indexing model from the issue text.