fix(helm): improve spiffe id configuration in ci overlay

User Story

As an operator using the OpenShell SPIRE CI/dev overlay as a reference for provider token grants on Kubernetes, I want the sandbox SPIFFE ID configuration to work across workspace modes and to anchor identity on Kubernetes-enforced attributes, so that sandbox pods reliably receive locatable, hard-to-spoof SVIDs regardless of workspace layout.

Problem Statement

The SPIRE overlay (deploy/helm/openshell/ci/values-spire-stack.yaml) assumes a single, fixed sandbox namespace and derives identity from a self-asserted pod annotation:

spiffeIDTemplate: 'spiffe://{{ .TrustDomain }}/openshell/sandbox/{{ index .PodMeta.Annotations "openshell.io/sandbox-id" }}'
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: openshell

Two problems:

1. Workspaces may break the selector. Sandbox namespaces depend on WorkspaceMode. Only Shared mode uses the fixed openshell namespace. Managed mode creates namespaces named openshell-{gateway_id}-{workspace}; Operator mode uses the workspace name as the namespace. In both, kubernetes.io/metadata.name is not openshell, so the namespaceSelector misses those pods and they receive no SVID — provider token grants silently stop working outside Shared mode. The template also carries no namespace/workspace or pod name, so an SVID can't be located or distinguished across workspaces.
2. Identity rests on self-asserted metadata. The discriminating segment is the pod annotation openshell.io/sandbox-id, which the pod author controls. Any pod matching the selectors that sets the same annotation value receives an identical SVID; uniqueness relies entirely on cluster RBAC restricting who can stamp it. Because this overlay is the reference operators copy, it should model anchoring identity on Kubernetes-enforced attributes rather than a free-form annotation.

Impact / Why This Matters

• Consequence of current behavior: SPIFFE-based provider token grants only work in Shared workspace mode; enabling Managed/Operator workspaces deprives sandbox pods of SVIDs and breaks token-grant/token-exchange flows. Separately, the shipped reference config teaches operators to base identity on a self-asserted annotation gated only by RBAC — a single-layer control with no defense-in-depth.
• Current workaround: Restrict SPIFFE to Shared mode, or hand-edit the overlay per deployment.
• Why insufficient: It couples the identity plane to one workspace mode, requires per-deployment overlay surgery, and propagates a weaker-than-necessary identity pattern to everyone who starts from this overlay.

Acceptance Criteria

• Sandbox pods receive SVIDs in Managed and Operator workspace modes, not just Shared.
• namespaceSelector matches OpenShell-managed workspace namespaces via a stable label rather than a hardcoded name.
• SPIFFE ID template encodes namespace and pod name (optionally the sandbox UUID) and no longer depends on the self-asserted openshell.io/sandbox-id annotation as its discriminator.
• Gateway/supervisor SVID validation still passes (trust-domain match unchanged; no Rust changes required).
• Operator-mode namespace labeling requirement documented.
• Example overlays that reconstruct the subject stay consistent: examples/spiffe-token-exchange-demo/podman/spire/register-sandbox.sh, examples/spiffe-token-grant-demo/k8s/workloads.yaml,
  .../token-issuer.js, .../README.md.
• Docs updated: docs/kubernetes/access-control.mdx.

Reproduction Steps

1. Use the in tree overlay to configure SPIRE
2. Token exchange or dynamic token grants for sandboxes in pods other than 'openshell' will fail

Environment

• OpenShell 0.0.117

Logs

Start with deploy/helm/openshell/ci/values-spire-stack.yaml, then compare the subject reconstruction in the listed example scripts, workloads, README, and docs/kubernetes/access-control.mdx. Done means workspace namespaces receive SVIDs, the template uses namespace and pod identity rather than the self-asserted annotation, validation remains compatible, and the Operator-mode labeling requirement and examples are documented consistently.