[EKS] [request]: `kubectl-connect` should accept `--role-arn`, so the Connect button works when cluster access is granted via an assumable role

### 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**
The `kubectl-connect` helper that ships in a VPC CloudShell environment opened by the EKS console's **Connect** button should accept a `--role-arn` argument and pass it through to `aws eks update-kubeconfig`.

Three concrete changes, in priority order:

1. Accept `--role-arn ` and forward it to `aws eks update-kubeconfig`.
2. Do not silently ignore unrecognised arguments — fail, or warn.
3. Do not short-circuit on an existing kubeconfig when arguments are supplied that would change the configuration.

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

EKS (and CloudShell, insofar as the helper ships with the VPC environment the Connect button creates)

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Access entries take exactly one literal IAM principal ARN and support no wildcard. For IAM Identity Center users, the role a permission set provisions into an account carries a 16-hex suffix that is regenerated on every reprovision, so a pinned `AWSReservedSSO__` ARN goes stale out of band. EKS does not validate that the principal exists, so the access entry silently grants nobody anything. This is #474, open since 2019.

The workaround AWS's own documentation points to — and which #2336 describes as what customers actually do — is to stop naming the SSO role in the access entry. Instead you create a durable IAM role, name *that* in the access entry, and put the rotating hash in the durable role's trust policy as an `ArnLike` condition on `aws:PrincipalArn`, which is the one place ARN patterns are supported. Users then reach the cluster with:

```bash
aws eks update-kubeconfig --name --region --role-arn
```

This works correctly from a normal shell. **It cannot be expressed through the Connect button**, which is the primary access path for private-endpoint clusters, because `kubectl-connect` always configures kubectl as the ambient console session principal — the very principal that, under this pattern, deliberately has no access entry.

The result is that the Connect button's headline behaviour ("CloudShell opens with `kubectl` already pointed at the cluster") produces a kubectl that cannot authenticate, and the error names no cause:

```
$ source kubectl-connect
Configuring kubectl for EKS cluster:
Added new context to /home/cloudshell-user/.kube/config-
Successfully configured kubectl for cluster:
Environment configured. KUBECONFIG is set to: /home/cloudshell-user/.kube/config-
⚠️ Configuration complete, but unable to connect to cluster
Current context:
E0902 12:57:00.525434 224 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
...
error: You must be logged in to the server (the server has asked for the client to provide credentials)
This may be due to:
• Network connectivity issues
• Invalid cluster credentials or permissions
• Cluster does not exist or is not accessible
• AWS credentials are incorrect or expired
```

None of the four suggested causes is the actual one. The credentials are valid, the network is fine (a 401 proves the API server was reached), and the cluster exists. The principal simply has no access entry.

Supplying the flag explicitly does not help — it is accepted without complaint and has no effect, and the helper additionally declines to reconfigure:

```
$ source kubectl-connect --role-arn arn:aws:iam::111122223333:role/eks-access/-admin
Cluster already configured, switching to existing configuration
Successfully configured kubectl for cluster:
...
error: You must be logged in to the server (the server has asked for the client to provide credentials)
```

So an operator who already knows the correct answer still cannot apply it through the supported path. Both behaviours compound: the flag is dropped, *and* the stale context is reused.

**Are you currently working around this issue?**
Yes, by documenting that users should disregard the helper the Connect button just ran for them, and instead run:

```bash
aws eks update-kubeconfig --name --region \
--role-arn arn:aws:iam::111122223333:role/eks-access/-admin --alias -role
kubectl config use-context -role
```

This works, but it means the Connect button actively misleads: it reports success, sets `KUBECONFIG`, changes the prompt to `[k8s: ]`, and leaves the user with a kubectl that 401s. Every operator has to learn this once by hitting an error message that points at four wrong causes.

**Additional context**

- Related: #474 (rolearn wildcard / Identity Center integration with the access entry API), open since 2019. #2336, closed as a duplicate of it, documents this same assumable-role approach as the customer workaround.
- This request is deliberately narrower than #474 and independent of it. Even if wildcard principal support ships, `--role-arn` pass-through remains useful for any cluster whose access is granted through an assumable role — cross-account access, break-glass roles, and CI principals all have the same shape.
- The fix appears to be a small change to an existing wrapper script rather than a service change.

Start by locating the kubectl-connect helper script and the existing call to aws eks update-kubeconfig. Exercise it with a cluster name, region, and --role-arn, including an already configured cluster, then verify that the role ARN is forwarded, unrecognised arguments are handled, and supplied configuration-changing arguments do not reuse stale configuration.

Written by the indexing model from the issue text.