[AWS::ElasticLoadBalancingV2::LoadBalancer] - [Enhancement] - Propagate LoadBalancer tags to service-managed ENIs

### Name of the resource

AWS::ElasticLoadBalancingV2::LoadBalancer

### Resource name

_No response_

### Description

When an Application Load Balancer (ALB) is created via `AWS::ElasticLoadBalancingV2::LoadBalancer`, the service automatically provisions Elastic Network Interfaces (ENIs) in the specified subnets. These **service-managed ENIs do not inherit the tags** defined on the LoadBalancer resource.

This is a **service-level limitation**: there is no mechanism - neither in CloudFormation nor via the ELBv2 API - to control the tags on ENIs created and managed by the ALB service.

While the `Tags` property on `AWS::ElasticLoadBalancingV2::LoadBalancer` works correctly for the ALB resource itself, the tags are **not propagated** to the underlying ENIs that the ALB creates and manages throughout its lifecycle.

### Problem

- ALBs create ENIs with descriptions like `ELB app//` in each configured subnet.
- These ENIs are **created, replaced, and deleted** autonomously by the ELB service (e.g., during scaling events, AZ changes, or internal maintenance).
- The ENIs have **no tags at all** - not even a reference back to the owning ALB.
- There is **no `TagSpecifications`-style mechanism** (as exists for EC2 Launch Templates) to define tags for these ENIs.

### Impact

Organizations that enforce **mandatory tagging policies** (e.g., via AWS Config rules, SCPs, or third-party compliance tools) face significant operational challenges:

- **Cost allocation**: Untagged ENIs cannot be attributed to a cost center, project, or team.
- **Compliance violations**: AWS Config rules like `required-tags` flag these ENIs as non-compliant — despite the resources being fully managed by AWS.
- **Operational overhead**: Workarounds require building and maintaining event-driven Lambda functions (via CloudTrail + EventBridge) to retroactively tag ENIs. These ENIs can be replaced at any time, creating a constant race condition.
- **Scale**: Organizations with many ALBs (50+) see hundreds of untagged ENIs, making VPC-level resource management and security auditing difficult.

### Expected Behavior

Tags defined on `AWS::ElasticLoadBalancingV2::LoadBalancer` should be **automatically propagated** to all ENIs created and managed by the ALB. When ENIs are replaced during the ALB lifecycle, the new ENIs should also receive the current tags from the parent LoadBalancer.

Alternatively, a new property like `EniTags` or `NetworkInterfaceTagSpecifications` could be introduced to allow explicit control over ENI tagging.

### Other Details

### Reproduction

1. Create an ALB via CloudFormation with tags:
```yaml
MyALB:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Properties:
Subnets: [subnet-aaa, subnet-bbb]
Tags:
- Key: Environment
Value: production
- Key: CostCenter
Value: 12345
```
2. After deployment, list the ENIs in the VPC:
```bash
aws ec2 describe-network-interfaces \
--filters "Name=description,Values=ELB app/*" \
--query "NetworkInterfaces[].{ID:NetworkInterfaceId,Desc:Description,Tags:TagSet}"
```
3. Observe: `TagSet` is **empty** on all ALB-managed ENIs.

No repository file, test, or implementation entry point is named. Start by reproducing the behavior with the provided CloudFormation ALB template, then run the AWS CLI network-interface query and determine whether tag propagation or an explicit ENI tag property can be supported; done means replacement ENIs receive the intended tags.

Written by the indexing model from the issue text.