[EKS] [bug]: Update VPC Endpoint Interface definition for the EKS Auth API

### 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**
Update the definition for the EKS Auth API (`eks-auth`) VPC Endpoint Interface:

* Service name: Consider updating from `com.amazonaws.{{ Region }} .eks-auth` to `eks.{{ Region }}.api.aws` (as documented)
* Certificate: Additional SANs for `eks-auth.eu-west-2.vpce.amazonaws.com` and `eks-auth.eu-west-2.amazonaws.com`

Also, consider updating the Pod Identity Agent to support both post and pre August 2024 DNS names `eks.region.amazonaws.com` and `eks.region.api.aws` (e.g. fallback behaviour).

**Which service(s) is this request for?**
EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
When deploying a private EKS cluster into a private VPC, several VPC Endpoint Interfaces are required, specifically, if using Pod Identity - EKS Auth API (`eks-auth`).

The below was observed when creating the `eks-auth` endpoint in the `eu-west-2` region with DNS disabled (as we manage DNS through a separate Route53 PHZ as all VPC endpoints are provisioned into a shared network). Accepting part of the below will be due to legacy reasons.

Noting https://docs.aws.amazon.com/eks/latest/userguide/vpc-interface-endpoints.html, endpoints created after August 2024 will be dual-stack. Our endpoint probably was created around that time, but even after re-creating it the certificate is still invalid against requests for `curl -I https://eks-auth.eu-west-2.amazonaws.com` which is inconsistent with other endpoints (such as the EKS API):

```
*.eks.eu-west-2.vpce.amazonaws.com
eks.eu-west-2.api.aws
eks.eu-west-2.vpce.amazonaws.com
eks.eu-west-2.amazonaws.com
```

vs.

```
{{ Ref }}.eks-auth.eu-west-2.api.aws
eks-auth.eu-west-2.api.aws
*.eks-auth.eu-west-2.vpce.amazonaws.com
lb-{{ Id }}-{{ Ref }}.eks-auth.eu-west-2.api.aws
```

For consistency, the following could be added: `eks-auth.eu-west-2.vpce.amazonaws.com` and `eks-auth.eu-west-2.amazonaws.com`.

This contributed to an issue that was hard to debug, there was no information (in the AWS Console) when creating this endpoint to suggest an alternative service DNS record was required.

The Pod Identity Service only seems to make requests for `eks-auth.{{ region }}.api.aws`, after timing out, there was no information in the EKS event logs to identify the hostname. Ideally it should support both pre and post August 2024 hostnames.

**Are you currently working around this issue?**
Route53 PHZs.

**Additional context**
None.

**Attachments**
None.

Start with the EKS VPC interface endpoints documentation linked in the issue and reproduce the eu-west-2 hostname and certificate check with curl. Done means the eks-auth endpoint definition covers the requested DNS and SAN names and Pod Identity supports both hostname generations, with the behavior documented or verified.

Written by the indexing model from the issue text.