[AWS::Redshift::Cluster] - [Enhancement] - Propagate tags to service-managed ENIs / Network interfaces

### Name of the resource

AWS::Redshift::Cluster

### Resource name

_No response_

### Description

When a provisioned Redshift cluster (`AWS::Redshift::Cluster`) is created in a VPC, the service provisions ENIs for each cluster node (leader node and compute nodes) in the cluster subnet group. These service-managed ENIs provide network connectivity and are visible in the EC2 console under "Node IP addresses" (both public and private). They do not inherit tags from the cluster resource.

### Problem

- Redshift creates one ENI per cluster node (1 leader + N compute nodes, depending on cluster type and size). For example, a `dc2.large` 2-node cluster creates 3 ENIs (1 leader + 2 compute).
- These ENIs carry no tags - no reference to the owning cluster, node role (leader/compute), or subnet group.
- ENIs can be replaced during cluster resize operations, elastic resize, node recovery, or availability zone relocation.
- There is no mechanism -via CloudFormation or the Redshift API- to control tags on these ENIs at creation time.

### Impact

Organizations enforcing mandatory tagging policies face:
- **Cost allocation gaps**: Untagged ENIs cannot be attributed to a project or team.
- **Compliance violations**: AWS Config rules like `required-tags` flag these ENIs as non-compliant.
- **Operational overhead**: Workarounds require event-driven Lambda functions to retroactively tag ENIs, with race conditions during resize or recovery events when ENIs are replaced.
- **Identification difficulty**: Without tags, there is no way to determine which cluster or node role an ENI belongs to without cross-referencing the Redshift `describe-clusters` API for node IP addresses.

### Expected Behavior

Tags defined on `AWS::Redshift::Cluster` should be automatically propagated to all ENIs created for cluster nodes. When ENIs are replaced during lifecycle events (resize, recovery, AZ relocation), new ENIs should receive the current tags from the parent cluster. Ideally, an additional tag indicating the node role (leader/compute) would also be applied.

### Other Details

- Node IP addresses (public and private) are exposed via the Redshift console and the `describe-clusters` CLI command, but the corresponding ENIs must be correlated manually.
- The same issue applies to `AWS::RedshiftServerless::Workgroup`, which also creates ENIs in the assigned subnets, though Serverless does not expose node IP addresses.

### Reproduction

1. Create a Redshift cluster with tags via CloudFormation:
```yaml
MyCluster:
Type: AWS::Redshift::Cluster
Properties:
ClusterType: multi-node
NumberOfNodes: 2
NodeType: dc2.large
DBName: mydb
MasterUsername: admin
MasterUserPassword: !Ref DBPassword
ClusterSubnetGroupName: !Ref MySubnetGroup
VpcSecurityGroupIds:
- sg-xxx
Tags:
- Key: Environment
Value: production
- Key: CostCenter
Value: "12345"
```
2. Retrieve node IP addresses:
```
aws redshift describe-clusters --cluster-identifier my-cluster \
--query "Clusters[].ClusterNodes[].{NodeRole:NodeRole,PrivateIP:PrivateIPAddress}"
```
3. Find the corresponding ENIs by private IP:
```
aws ec2 describe-network-interfaces \
--filters "Name=addresses.private-ip-address,Values=" \
--query "NetworkInterfaces[].{ID:NetworkInterfaceId,Desc:Description,Tags:TagSet}"
```
4. Observe: `TagSet` is empty on the Redshift-managed ENIs.

No repository files, tests, or entry points are named. Start with the Redshift cluster reproduction and the CloudFormation coverage process, then determine whether AWS supports propagating cluster or workgroup tags to service-managed ENIs. Done means the requested behavior is supported for creation and replacement lifecycle events, including the stated tag expectations.

Written by the indexing model from the issue text.