Address header secret handling in static mode for type: direct

Use SecretKeyRef env vars on the vMCP Deployment instead of inlining
secret values into the backend ConfigMap. Mirrors the existing pattern
from MCPRemoteProxy. ConfigMap stores only env var names, vMCP resolves
values at runtime via secrets.EnvironmentProvider.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: ChrisJBurns

rfcs/THV-0055-mcpremoteendpoint-unified-remote-backends.md

@@ -580,7 +580,7 @@ strict YAML parsing. Writing new fields (`Type`, `CABundlePath`, `Headers`)
 to the ConfigMap before updating the vMCP binary will cause a startup failure.
 
 Implementation order:
-1. Add `Type`, `CABundlePath`, and `Headers` fields to `StaticBackendConfig`
+1. Add `Type`, `CABundlePath`, and `HeaderEnvVars` fields to `StaticBackendConfig`
 2. Update the vMCP binary and the roundtrip test in
    `pkg/vmcp/config/crd_cli_roundtrip_test.go`
 3. Deploy the updated vMCP image **before** the operator starts writing these
@@ -589,11 +589,27 @@ Implementation order:
 Additional touch points:
 - `listMCPRemoteEndpointsAsMap()` — new function for ConfigMap generation
 - `getExternalAuthConfigNameFromWorkload()` — add MCPRemoteEndpoint case
-- `headerForward.addHeadersFromSecret` requires K8s Secret resolution at
-  ConfigMap generation time (static mode has no K8s API access at runtime)
-- `vmcp.Backend` needs a `Headers` field for resolved header values
 - Deployment volume mount logic for `caBundleRef` ConfigMaps
 
+**Header secret handling in static mode:** Secret values MUST NOT be inlined
+into the backend ConfigMap. Instead, the operator uses the same `SecretKeyRef`
+pattern that MCPRemoteProxy already uses:
+
+1. For each `type: direct` endpoint with `addHeadersFromSecret` entries, the
+   operator adds `SecretKeyRef` environment variables to the **vMCP Deployment**
+   (e.g. `TOOLHIVE_SECRET_HEADER_FORWARD_X_API_KEY_<ENDPOINT_NAME>`).
+2. The static backend ConfigMap stores only the env var names — never the
+   secret values themselves.
+3. At runtime, vMCP resolves header values via the existing
+   `secrets.EnvironmentProvider`, identical to how MCPRemoteProxy pods handle
+   this today.
+
+This ensures no key material is written to ConfigMaps or stored in etcd in
+plaintext. The trade-off is that adding or removing `addHeadersFromSecret`
+entries on a direct endpoint triggers a vMCP Deployment update (and therefore
+a pod restart), consistent with how CA bundle changes already behave in static
+mode.
+
 **CA bundle in static mode:** The operator mounts the `caBundleRef` ConfigMap
 as a volume into the vMCP pod at `/etc/toolhive/ca-bundles/<endpoint-name>/ca.crt`.
 The generated backend ConfigMap includes the mount path so vMCP can construct
@@ -904,11 +920,13 @@ can manage backends) and couples backend lifecycle to vMCP reconciliation.
 
 ### Phase 2: Static Mode Integration
 
-1. Add `Type`, `CABundlePath`, `Headers` fields to `StaticBackendConfig`;
+1. Add `Type`, `CABundlePath`, `HeaderEnvVars` fields to `StaticBackendConfig`;
    update vMCP binary and roundtrip test BEFORE operator starts writing them
 2. Update VirtualMCPServer controller: `listMCPRemoteEndpointsAsMap()`,
    `getExternalAuthConfigNameFromWorkload()`, ConfigMap generation
-3. Implement header secret resolution at ConfigMap generation time
+3. Add `SecretKeyRef` env vars to vMCP Deployment for `addHeadersFromSecret`
+   entries on `type: direct` endpoints; store env var names (not values) in
+   backend ConfigMap
 4. Mount CA bundle ConfigMaps as volumes
 5. Implement post-exchange audience validation in token exchange strategy
 6. Extend vMCP audit middleware for `type: direct` (remote URL, auth outcome,