[EKS] [Feature Request]: kube-proxy addon configuration schema should support iptables.masqueradeAll for IPVS to iptables migration

## Summary

The EKS managed kube-proxy addon configuration schema does not support `iptables.masqueradeAll` as a configurable property via `configuration_values`. This is a blocker for customers migrating from IPVS to iptables mode as part of the EKS 1.35/1.36 upgrade path.

## Background

AWS has deprecated IPVS in EKS 1.35 and will remove it in EKS 1.36, requiring all customers to migrate to iptables mode. During this migration,
`aws-eks-nodeagent` (part of VPC CNI addon v1.21.1) fails to connect to the Kubernetes API server (`172.20.0.1:443`) when kube-proxy runs in iptables mode with the default `masqueradeAll: false` setting.

**Root cause:** iptables mode without `masqueradeAll: true` breaks return traffic for `hostNetwork` pods connecting to ClusterIPs because conntrack cannot properly track the connection without SNAT. `aws-eks-nodeagent` runs with `hostNetwork: true` and is therefore affected.

**Resolution:** Setting `masqueradeAll: true` in the `kube-proxy-config` ConfigMap resolves the issue. This has been confirmed by AWS Support (Case 178071432800885) who has also validated the findings in their lab environment and agreed to raise it with the service team.

## Problem

When attempting to pass `iptables.masqueradeAll` via the addon `configuration_values`, the EKS API rejects it:

```json
{
"requestParameters": {
"addonName": "kube-proxy",
"configurationValues": "{\"iptables\":{\"masqueradeAll\":true}}"
},
"responseElements": {
"message": "ConfigurationValue provided in request is not supported:
Json schema validation failed with error: [$.iptables: is not defined
in the schema and the schema does not allow additional properties]"
}
}
```

The current kube-proxy addon schema only allows:
- `mode` (iptables / ipvs / nftables)
- `ipvs.scheduler`
- `podAnnotations`
- `podLabels`
- `resources`

There is no `iptables` block in the schema at all.

## Impact

- Affects all EKS customers migrating from IPVS to iptables as part of EKS 1.35/1.36 upgrade
- `aws-eks-nodeagent` (VPC CNI v1.21.1) crashes with CrashLoopBackOff on all nodes after switching to iptables mode
- Customers are forced to manually patch the `kube-proxy-config` ConfigMap outside the addon API — this creates a risk of the setting being lost
during future addon upgrades
- IaC tools like Terraform cannot manage this setting through the addon resource, requiring additional post-apply steps

## Expected Behavior

Customers should be able to set `iptables.masqueradeAll: true` via the addon `configuration_values`:

```json
{
"mode": "iptables",
"iptables": {
"masqueradeAll": true
}
}
```

## Requested Changes

1. Add `iptables.masqueradeAll` to the kube-proxy addon configuration schema
2. Consider setting `masqueradeAll: true` as the **default** when mode is set to `iptables`, since it is required for AWS-managed components (aws-eks-nodeagent) to function correctly
3. Update the IPVS to iptables migration documentation to mention this requirement

## Environment

- EKS Version: 1.35
- kube-proxy addon version: v1.35.3-eksbuild.2
- VPC CNI addon version: v1.21.1-eksbuild.1
- aws-network-policy-agent version: v1.3.1-eksbuild.1

No repository file, test, or implementation entry point is identified; this is a request for an EKS managed kube-proxy addon schema change. Start by reviewing the EKS addon configuration schema and the IPVS-to-iptables migration documentation, then confirm the work is done when configuration_values accepts iptables.masqueradeAll and the migration guidance covers the requirement.

Written by the indexing model from the issue text.