aws-cdk-lib: Replica Secrets with Replica KMS keys

### Describe the bug

Unable to attach CfnReplicaKey to replicated secrets in the ReplicaRegion[] because you cannot get an IKey for this resource across regions. This means replicated secrets that use KMS keys have to manually be updated in console after replica region deploys in order to attach the replica KMS key (or any KMS key I believe).

This is an inconsistency because of the way SecretsManager has decided to run all of it's logic from the "primary region" whereas KMS runs it's replication logic from the "secondary regions". This inconsistency between services is what leads to this issue.

### Expected Behavior

Be able to attach a KMS key (specifically a replica key) when it is created in secondary regions to a secret replicated into that region.

### Current Behavior

Sharing secrets across accounts, created a secret in us-east-1 with a defined KMS key and then replicated it into us-west-2. I replicated my KMS key as well but have no way to attach this back to the ReplicaRegions[] in my code.

Example of secret created in us-east-1: (defaultKmsKey obj

```
const defaultKmsKey = new aws_kms.CfnKey(
this,
'defaultProjectSecretsKMSKey',
{
description: 'KMS key for the secret secret',
multiRegion: true,
keyPolicy: getKmsKeyPolicy(),
},
)
new aws_secretsmanager.Secret(this, 'defaultProjectSecrets', {
secretName: 'mysecretsecret',
// Have to convert CfnKey into IKey to use it as the encryption key to use the attrArn to retrieve it as an IKey
encryptionKey: aws_kms.Key.fromKeyArn(
this,
'defaultKmsKeyAsKey',
defaultKmsKey.attrArn,
),
replicaRegions: [
{ region: 'us-west-2' }
],
})
```

In my secondary regions I am doing this:

```
new aws_kms.CfnReplicaKey(this, 'defaultProjectSecretsKMSKeyReplica', {
description: 'Replicated KMS key for the secret secret',
// This was deployed into us-east-1 first in order to pull this. Could store it in ParameterStore or something but this is fine for now.
primaryKeyArn: 'my-us-east-1-kms-key-arn',
keyPolicy: getKmsKeyPolicy(),
})
```

The problem here is that I cannot even attach this CfnReplicaKey back to my secret in replica regions because when I synth/deploy in that region the `fromKeyArn()` would fail since it's in a different region.

### Reproduction Steps

1. Create Secret with a KMS key in east-1 and set it to replicate to west-2
2. Now secret in east-1 has your kms key, and secret in west-2 has the default AWS key.
3. This secret can no longer be accessed across accounts now because it has the "default" KMS key on it in west-2.
4. Replicate your KMS key into us-west-2 and you have no way to attach it (via cdk) back to the us-east-1 secret.

ReplicaRegion[] is expecting an IKey for encryptionKey prop but you cannot get an IKey because the KMS key you want to attach exists in another region and would fail to import via `fromKeyArn()` and even if it worked would be dirty.

### Possible Solution

Allow a call on the Secret class from "replicated regions" that will allow you to update/attach a KMS key. Instead of declaring this @ create time.

### Additional Information/Context

_No response_

### CDK CLI Version

2.126

### Framework Version

_No response_

### Node.js Version

18

### OS

macos

### Language

TypeScript

### Language Version

_No response_

### Other information

_No response_

Start by tracing the Secret class handling of ReplicaRegion[] and encryptionKey, then compare it with the CfnReplicaKey resource behavior across regions. Define how a replica-region KMS key could be attached without invalid cross-region IKey imports, and verify the design through synth/deploy reproduction using the us-east-1 and us-west-2 setup described.

Written by the indexing model from the issue text.