Implement Webhook minted tokens from upstream 1.37 (KEP 6060) #4489

Kubernetes 1.37 introduced alpha support for webhook-bound service account tokens, which are formalized in https://kep.k8s.io/6060

Basically a TokenRequest can be bound to a ValidatingWebhookConfiguration or MutatingWebhookConfiguration, producing a token that admission webhooks can use (via TokenReview) to verify that incoming AdmissionReview requests genuinely originate from the API server. The token embeds the webhook configuration's UID and is invalidated when the configuration is deleted or recreated - essentially the same as they do for pod-, node-, and secret-bound tokens; just now for ServiceAccounts as well.

For us as kcp project we basically need to decide on the following, three things:

1. Who may bind? Which workspace-level permission should you need to "request a token bound to webhook configuration X in workspace Y" Do we reuse the existing RBAC verbs on validatingwebhookconfigurations/mutatingwebhookconfigurations (e.g. require get or a custom verb like bind), or introduce a kcp-specific policy? This is security-sensitive because a bound token is effectively proof that "kcp called you" — whoever can mint one can impersonate the control plane toward that webhook backend.
2. Scope of validity: a token minted in workspace Y is validated wherever its TokenReview lands, with cross-shard lookup via shardlookup. That's consistent with how SA/secret-bound tokens already work, but it should be an explicit decision that a webhook backend serving many workspaces must TokenReview against the right logical cluster.
3. Audience semantics: upstream rejects binding if the requested audience overlaps the API server's audiences. the token is for the webhook, not for kcp. kcp has a more layered audience story (shards, front-proxy, per-workspace authentication via WorkspaceAuthentication), so you need to pin down which audience set the "must not overlap" check compares against.