[EKS] [request]: Support weighted capacity for multiple instance types in Managed Node Groups (incl. Spot)

### 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**
Add first-class support in EKS Managed Node Groups (MNGs) to specify relative capacity weights per instance type, equivalent to Auto Scaling Groups’ InstanceTypeWeightings. When weights are present, the node group should interpret desired/target size as capacity units, not raw instance count.

**Which service(s) is this request for?**
Amazon EKS — Managed Node Groups (integration with EC2 Auto Scaling).

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
MNGs let me list multiple instance types, but there’s no way to control their relative mix. This is most painful on Spot: when one type is temporarily unavailable, I only care that my total cluster resources are satisfied (e.g., “8 vCPU / 32 GiB”), not the exact number of nodes. Today, to achieve a preferred blend I must create multiple node groups or adopt an additional controller, both add operational overhead and split my scaling surface area.

**Are you currently working around this issue?**
I manually update the ASG with the instance types and weighted capacity. This then manages the instances by weight rather than count of nodes.

**Additional context**
- Auto Scaling Groups already support Instance Type Weightings. Feature parity in MNGs would reduce operational overhead and improve Spot success rates without requiring multiple node groups or external controllers.

- We understand that “same total resources” is not equal to “identical scheduling”. That’s acceptable, the goal is to keep target capacity units satisfied while letting EKS/ASG pick the best available types.

**Proposed solution**
Expose weights per instance type in the MNG API/CFN/eksctl and pass through to the underlying ASG (or an equivalent EKS abstraction). When weights are set, treat desiredSize/minSize/maxSize as capacity units.
```yaml
managedNodeGroup:
instanceTypes:
- type: m6g.large
weight: 1
- type: m6g.xlarge
weight: 2
- type: c7g.large
weight: 1
capacityType: SPOT
spotAllocationStrategy: capacity-optimized-prioritized
desiredSize: 6 # interpreted as capacity units, not node count
```

**Attachments**

Start by tracing the proposed EKS Managed Node Group API, CloudFormation/eksctl surfaces, and the underlying Auto Scaling integration named in the issue; no file or test entry point is provided. Done means the weight configuration and capacity-unit semantics are defined across the named surfaces and verified for desired, minimum, and maximum sizes.

Written by the indexing model from the issue text.