[EKS] [BUG] EKS breaks when cluster's launched with a HEX name

When deploying EKS clusters with hex names (i.e `0x01`), the cluster silently breaks and never comes alive. Any attempt in accessing the cluster results in a failure as managed cluster access (`aws-auth`) does not get configured.

Only meaningful logs I managed to collect during experiments:

```
{
"timestamp": 1735586849000,
"message": "E1230 19:27:29.674589 12 webhook.go:154] Failed to make webhook authenticator request: unknown",
"ingestionTime": 1735586853443
},
{
"timestamp": 1735586849000,
"message": "E1230 19:27:29.674635 12 authentication.go:73] \"Unable to authenticate the request\" err=\"[invalid bearer token, unknown]\"",
"ingestionTime": 1735586853443
}
```

```
{\"Code\":\"SignatureDoesNotMatch\",\"Message\":\"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.\",\"Type\":\"Sender\"},\"RequestId\":\"ba389980-8472-4bca-93a8-26baeb070ebd\"}" method=POST path=/authenticate...
```

[Relevant slack thread](https://kubernetes.slack.com/archives/C8SH2GSL9/p1735313885990789)

No repository files or tests are named. Start by reproducing an EKS deployment with a hexadecimal cluster name such as `0x01`, then inspect the managed cluster access (`aws-auth`) configuration and the authentication logs; done means the cluster becomes accessible and requests no longer fail with signature or bearer-token errors.

Written by the indexing model from the issue text.