[EKS] [request]: Allow access policy AmazonEKSAdminPolicy to manage Roles / RoleBindings (add verbs "escalate" and "bind")

### 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 [documentation shows `AmazonEKSAdminPolicy`](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksadminpolicy) has access to `rbac.authorization.k8s.io` resources `rolebindings, roles` with verbs `create, delete, deletecollection, get, list, patch, update, watch`. However when I attempt to use this access policy within the scoped namespace to create a RoleBinding, I get the following error:

`$ kubectl create rolebinding -n default austin-test --clusterrole view --group example-corp:my-group
error: failed to create rolebinding: rolebindings.rbac.authorization.k8s.io "austin-test" is forbidden: user "arn:aws-us-gov:sts::111111111111:assumed-role/austin-role/botocore-session-1759252895" (groups=["example-corp:my-group" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:`

and following the error message, it lists all the get/list/watch permissions declared in the requested `view` ClusterRole

[From looking into this in the past](https://github.com/aws/containers-roadmap/issues/185#issuecomment-2457910292), the error seems due to access policies less than `AmazonEKSClusterAdminPolicy` are limited to not capable of creating (Cluster)Role / (Cluster)RoleBinding resources b/c they do not include `escalate` or `bind` verbs _and_ their rules are not visible to kubernetes internals when it is evaluating if the user has at least the permissions declared in the Role / RoleBinding request.

**So I think this can be resolved by adding [`escalate` and `bind`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) verbs for the `rbac.authorization.k8s.io` resources `rolebindings, roles` to the access policy `AmazonEKSAdminPolicy`. This will let `AmazonEKSAdminPolicy` manage rolebindings and roles within namespaces as it seems intended.**

**Which service(s) is this request for?**
EKS (us-gov-east-1, tho I expect the issue exists in all regions)

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
From documentation, the access policy `AmazonEKSAdminPolicy` seems ideal for giving someone significant access within a namespace, including management of Roles and RoleBindings, but this access policy does not correctly allow an IAM principal to manage Roles and RoleBindings.

**Are you currently working around this issue?**
Either:
1. Granting access policy `AmazonEKSClusterAdminPolicy` to IAM principals scoped to a namespace - this grants more permissions than are ideal for giving someone admin access within a namespace (as noted in the docs)
2. Creating custom ClusterRole for namespace admins and associating it to the IAM principal via access entry + group. This works but it'd be great to use the `AmazonEKSAdminPolicy` access policy as it seems to be intended for.

Start with the linked AmazonEKSAdminPolicy permissions documentation and the Kubernetes RBAC privilege-escalation guidance cited in the issue. Compare the documented Role and RoleBinding verbs with the requested behavior; done means namespace-scoped AmazonEKSAdminPolicy access can manage those resources without the reported privilege-escalation error.

Written by the indexing model from the issue text.