[ECS] [request]: Propagate tags to trunk ENI created by ECS on EC2

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
Please add AWS-native support for **automatic tagging / tag inheritance** for the EC2 **trunk network interface (ENI)** created for **ECS on EC2** (EC2 trunking), so that mandatory ENI tagging requirements can be met (without customer-managed automation).

**Which service(s) is this request for?**
ECS (on EC2) + EC2 networking (trunk ENI / EC2 trunking)

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
We run an ECS cluster on EC2 capacity provided by an Auto Scaling Group with a Launch Template. The Launch Template is configured to apply **Resource tags** to:
- Instances
- Network interfaces
- Volumes

However, each ECS container instance ends up with:
- a primary ENI (interface type: `Elastic network interface`) that is tagged as expected, and
- an additional ENI with interface type: `trunk` that is created/attached by ECS/EC2 trunking and has **no tags**.

Outcome we are trying to achieve:
- Ensure **all ENIs**, including the ECS/EC2-trunking-created **trunk ENI**, have our mandatory tags (for governance/cost allocation). Launch Template just says "Network interfaces" (not limited by type).

Why it is hard today:
- Launch Template / ASG tag propagation does not apply to the trunk ENI (because it is created later by the service).
- This results in continuous governance/compliance reporting violations and manual operational effort.
- We want an AWS-native solution, not a custom remediation function (like an Lambda).

Impact:
- Compliance/reporting violations for mandatory tag policies on ENIs (It's not blocked by SCP yet, but shows up in internal reporting).
- Ongoing operational overhead to explain/clean up untagged AWS-created resources.

**Are you currently working around this issue?**
"Keeping" compliance violations in some cases or creating a custom Lambda (using EventBridge) for solely for tagging AWS-created trunk ENIs. We are not happy with this overhead. We want to avoid building/operating custom remediation.