feat(kubernetes): support operator workspace mode with external compute drivers

User Story

As an operator running OpenShell Kubernetes compute drivers out of process, I want operator workspace mode to preserve live namespace authorization, so that I can standardize on external drivers without giving up the operator-managed namespace workflow or its security guarantees.

Problem Statement

PR #2822 adds standalone first-party compute drivers. External Kubernetes drivers support shared and managed workspace modes, but currently reject operator mode.

Operator mode depends on a live namespace allowlist populated from a Kubernetes namespace-label watcher or a hot-reloaded file. With the in-process Kubernetes driver, the gateway and driver share this allowlist in memory. Once the driver runs in another process, that authorization state is process-local and is not available to the gateway when it validates projected Kubernetes ServiceAccount tokens. A one-time snapshot is insufficient because namespaces can be added, removed, relisted, or reloaded while the gateway is running.

Impact / Why This Matters

Today, deployments using operator workspace mode must keep the Kubernetes driver in process. Alternatively, they can run the driver externally only by switching to shared or managed mode. These workarounds are insufficient for deployments that use pre-created, operator-controlled namespaces and want to standardize on the out-of-process driver model introduced by #2822.

Without an explicit cross-process authorization contract, accepting this configuration would either reject valid ServiceAccount bootstrap requests or risk authorizing against stale namespace state.

Proposed Design

Support workspace_mode = "operator" when the Kubernetes compute driver runs externally, with behavior equivalent to the in-process mode:

• Namespace additions and removals discovered through label watching are reflected in subsequent gateway authorization decisions.
• Watch relists and file reloads replace the effective allowlist consistently.
• Kubernetes ServiceAccount bootstrap remains fail-closed whenever current authorization state cannot be obtained or validated.
• Operators configure operator mode through the same Kubernetes driver settings whether the driver is in process or external.

The implementation should define an explicit cross-process authorization contract. This could be a generic driver authorization capability or another mechanism, but the externally observable behavior should not depend on that choice.

Acceptance Criteria

• An external Kubernetes compute driver can start with workspace_mode = "operator".
• Namespace additions and removals from the configured label source are reflected in gateway ServiceAccount bootstrap authorization.
• A watcher relist replaces the effective namespace allowlist without leaving stale authorization entries.
• Successful file-source reloads replace the effective namespace allowlist, while failed reloads do not broaden authorization.
• Gateway ServiceAccount bootstrap fails closed when current operator namespace authorization state is unavailable or invalid.
• External Kubernetes operator-mode E2E coverage exercises at least one live allowlist update and verifies the resulting authorization behavior.
• Existing external shared and managed behavior and in-process operator behavior remain unchanged.
• The external-operator startup restriction introduced in #2822 is removed.

Alternatives Considered

Continue rejecting external operator mode. This is safe and is the temporary behavior in #2822, but it prevents operator-namespace deployments from adopting external Kubernetes drivers.

Copy the allowlist once at startup. This does not preserve label-watch or file-reload semantics and can leave authorization stale as namespaces change.

Have the gateway independently watch the same labels or file. This may be viable, but it duplicates state ownership and configuration; the design should first determine the clearest explicit contract between the gateway and external driver.

Agent Investigation

• #2822 introduces the standalone first-party driver path and the temporary explicit rejection.
• #2417 tracks the compute-driver registry work underlying the stack.
• #2061 covers the broader out-of-process compute-driver direction.
• #2486 provides related Kubernetes/operator-mode context.

Start with PR #2822 and trace the external Kubernetes driver startup restriction, gateway ServiceAccount bootstrap authorization, and the operator namespace watcher or file-reload paths. Review related context in #2417, #2061, and #2486 before choosing the cross-process authorization contract. Done means the acceptance criteria pass, including live allowlist updates, fail-closed behavior, and unchanged shared, managed, and in-process operator modes.