feat: support file-based / external API key credentials (API key counterpart of #311)

Problem

We authenticate to Temporal Cloud with API keys and run the controller on GKE.
Our security policy requires secrets to be held in GCP Secret Manager and retrieved by the
workload at runtime, rather than stored as Kubernetes Secrets in etcd.

Today Connection accepts credentials only via apiKeySecretRef, a SecretKeySelector that
must name a Kubernetes Secret in the same namespace. The controller resolves it through the
Kubernetes API, and it also injects TEMPORAL_API_KEY into managed worker pods via
secretKeyRef. There is no way to supply the API key from a file, from a volume mounted by
the Secrets Store CSI driver, or from an external secret manager.

#311 proposes file-based credentials, but is explicitly scoped to mTLS. There is currently no
equivalent for API key auth, so organizations that standardize on API keys cannot benefit
from it.

Why this matters

• The Secrets Store CSI driver can mount secrets into pods without creating a Kubernetes
  Secret (secretObjects is optional). That pattern is unusable with the controller today,
  because credentials are resolved through the API server rather than through the pod-spec
  layer.
• Same RBAC motivation as #311: the chart grants secrets get/list/watch in a ClusterRole.
  On a cluster shared by multiple teams, that is considerably wider than the controller's
  actual need. A file-based mode would let deployers drop the rule entirely.
• Temporal's own guidance recommends retrieving API keys from a key management system rather
  than hardcoding them, and the Go SDK already supports this through
  client.NewAPIKeyDynamicCredentials.

Proposed

An alternative to apiKeySecretRef on ConnectionSpec:

spec:
  hostPort: "us-east-1.aws.api.temporal.io:7233"
  apiKeyFile:
    path: /etc/temporal/api-key

The controller would read the file on each use. Since #301 already made the API key re-read
per RPC via NewAPIKeyDynamicCredentials, this is largely a change of source rather than a
change of lifecycle.

When this mode is used, the controller would skip credential injection into worker pods and
leave credential delivery to the pod-spec layer (volumes / CSI), consistent with the scope
of #311.

Related

• #311 — file-based mTLS credentials (the mTLS counterpart of this request)
• #246 — controller as a library (would also address this, by allowing a pre-configured client)
• #301 — the API key is already re-read per RPC