Add a built-in Kubernetes service account ClaimMapper selectable via `authorization.claimMapper`

Is your feature request related to a problem?

Self-hosting on Kubernetes, the natural caller identity is a projected service account
token. Mapping those to Temporal namespace roles currently requires a custom
ClaimMapper and therefore a custom server binary, which means owning the rebuild for
every Temporal patch release.

This is not a bespoke integration: every Kubernetes deployment has SA tokens, an OIDC
JWKS endpoint, and subjects in the fixed form system:serviceaccount:<ns>:<name>.

Describe the solution you'd like

A third case in GetClaimMapperFromConfig, alongside "" and "default":

global:
  authorization:
    authorizer: default
    claimMapper: k8s-sa
    jwtKeyProvider:
      keySourceURIs: ["https://<cluster-oidc-issuer>/openid/v1/jwks"]
    audience: temporal-cluster
    k8sServiceAccount:
      issuer: "https://<cluster-oidc-issuer>/"
      rulesFile: /etc/temporal/k8s-sa-rules.yaml

Rules grant existing <namespace>:<role> permissions per service account, so the
built-in defaultAuthorizer is unchanged:

rules:
  - serviceAccount: "platform/order-worker"
    permissions: ["orders:write", "orders:worker"]

Token signatures validate against the existing JWTKeyProvider; the mapper adds issuer
and subject handling only.

Why this rather than #8636

#8636 asks for a plugin architecture. This asks for nothing new architecturally: it is
in-process, compile-time checked, on the same hot path as default, and follows the
precedent set in #1134 — "we do need to provide a way to select built-in plugins like
these through config, so that they could be used with the standard docker images."

Additional context

We have a working implementation with unit tests covering signature validation,
audience and issuer checks (including the trailing-slash difference between AKS token
iss claims and the discovery document), subject parsing, rule validation, and
per-namespace role mapping. Happy to open a PR if there's interest.

Start at GetClaimMapperFromConfig and inspect the existing default claim mapper, defaultAuthorizer, and JWTKeyProvider configuration paths. Use the stated unit-test coverage as the validation checklist: signature, audience, issuer, subject parsing, rule validation, and per-namespace role mapping. Done means k8s-sa is selectable through authorization.claimMapper without changing defaultAuthorizer.