aws-iam: Assigning the same user policies in multiple stacks can cause previous policies to be overwritten

### Describe the bug

When a user is imported into multiple CDK stacks, and is granted policies through `ISecret.grantRead` (or similar), the last deployed stack's policy overrides whatever was granted before on the user.

Seems to be similar to https://github.com/aws/aws-cdk/issues/23080, but for users instead of roles.

### Regression Issue

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

### Last Known Working CDK Library Version

_No response_

### Expected Behavior

Each policy should be unique on a per-stack basis, such that each stack's policies don't overwrite one another.

### Current Behavior

Only the last deployed stack's policy is attached to the user, overwriting all previous policies.

### Reproduction Steps

With a created user, bucket, and function, deploy these two stacks:

```typescript
export class FirstStack extends cdk.Stack {
constructor(scope: Construct, id: string, props: FirstStackProps) {
super(scope, id, props);

const bucket = new Bucket(this, 'Bucket', {
autoDeleteObjects: true,
removalPolicy: RemovalPolicy.DESTROY
})
const user = User.fromUserArn(this, "User", "")
bucket.grantWrite(user)
}
}

export class SecondStack extends cdk.Stack {
constructor(scope: Construct, id: string, props: SecondStackProps) {
super(scope, id, props);

const fn = new Function(this, 'MyFn', ...)
const user = User.fromUserArn(this, "User", "")
fn.grantInvoke(user)
}
}
```

### Possible Solution

Perhaps a similar fix to what was done for https://github.com/aws/aws-cdk/issues/23080?

### Additional Information/Context

_No response_

### AWS CDK Library version (aws-cdk-lib)

2.235.1

### AWS CDK CLI version

2.1118.4

### Node.js Version

18.20.8

### OS

Linux

### Language

TypeScript

### Language Version

_No response_

### Other information

_No response_

Start with the two stack definitions in the reproduction and deploy them using aws-cdk-lib 2.235.1, checking the imported user's resulting policies after each deployment. Trace the grantWrite and grantInvoke paths for the imported User and compare the behavior with issue 23080. Done means both stacks' policies remain attached to the user instead of the last deployment replacing earlier policies.

Written by the indexing model from the issue text.