fix(providers): preserve stable placeholders in split supervisor

Reconcile the stable-placeholder branch with the separate supervisor and
workload boundary. Keep stable delivery metadata and capability checks on
startup, refresh, failure recovery, rotation, and detach. Transfer only the
prepared environment to workload processes.

Adapt the persistent-process E2E fixture to install its backend trust root in
the supervisor image, run its backend on the private Docker bridge, and
restore the wrapper-owned gateway configuration. Preserve archive ownership
and use host-visible TLS fixture paths for containerized CI.
Regenerate the merged public bindings and retain stored-data compatibility
coverage for both branches.

Signed-off-by: Shiju <shiju@nvidia.com>

Author: shiju-nv

.agents/skills/build-openshell-mxc-windows/SKILL.md

@@ -115,7 +115,7 @@ The lane targets a Windows host with Visual Studio Build Tools and rustup.
 | Visual C++ ARM64 tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.ARM64 -property installationPath` | Required for native ARM64 check, build, and tests and for x64-to-ARM64 check/build. Tests always require a native runner. |
 | Visual C++ ARM64 Spectre-mitigated libraries | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Runtimes.ARM64.Spectre -property installationPath` | Required by `regorus` through `msvc_spectre_libs`; the build fails when the selected MSVC toolset lacks `lib\spectre\arm64`. |
 | Visual C++ Clang tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Llvm.Clang -property installationPath` | Provides host-native `libclang.dll` for `bindgen` and `clang-cl.exe` for ARM64 crypto dependencies such as `aws-lc-sys`. On ARM64, the wrapper uses `VC\Tools\Llvm\Arm64\bin`. |
-| Visual C++ CMake tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.CMake.Project -property installationPath` | Provides CMake and Ninja for bundled Z3 and other native dependencies. The x64-to-ARM64 path adds Ninja to `PATH`; Z3 uses MSVC's Visual Studio generator. |
+| Visual C++ CMake tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.CMake.Project -property installationPath` | Provides CMake and Ninja for native dependencies. The x64-to-ARM64 path adds Ninja to `PATH`; Z3 uses an architecture-specific prebuilt release. |
 | Windows SDK | `where.exe rc.exe` from a Developer PowerShell | Install an SDK containing target libraries and ARM64 tools. |
 | Rust via rustup | `rustc --version` | Add each target being validated: `x86_64-pc-windows-msvc` and/or `aarch64-pc-windows-msvc`. The wrapper also adds the selected target. |
 | mise | `mise --version` | Used as a task runner only. |
@@ -135,6 +135,8 @@ from this skill.
 | `CARGO_TARGET_DIR` | `target` under repo root | Override Cargo output location. Use a short absolute path when x64-to-ARM64 builds approach Windows path-length limits. |
 | `Z3_LIBRARY_PATH_OVERRIDE` | unset | Directory containing an x64 system `libz3.lib`; not valid for ARM64. |
 | `Z3_SYS_Z3_HEADER` | unset | Full `z3.h` path required with a system Z3 library. |
+| `Z3_SYS_Z3_VERSION` | `4.16.0` | Pinned official prebuilt Z3 release selected by the wrapper. |
+| `READ_ONLY_GITHUB_TOKEN` | unset | Optional token for the Z3 release lookup; GitHub Actions supplies `github.token`. |
 | `RUSTC_WRAPPER` | inherited | The wrapper resolves an available command to an absolute path. If it is unavailable, the wrapper warns and continues without compiler caching. |
 
 Legacy fork variables such as `OPENSHELL_UPSTREAM`,
@@ -203,8 +205,7 @@ jobs in the current mirror push run, or push a new mirrored commit. The binaries
 The ARM64 check/build steps in this x64-host contract are cross-builds. The
 wrapper discovers and adds host-native LLVM and Ninja to `PATH`, requires the
 ARM64 compiler and Spectre-mitigated libraries, lets ARM64 crypto crates select
-`clang-cl`, and builds bundled Z3 with native MSVC `cl.exe` and the Visual
-Studio generator.
+`clang-cl`, and downloads the official prebuilt ARM64 Z3 static library.
 
 On ARM64 hosts, validate the native ARM64 check, build, and test path. The
 wrapper rejects test targets that do not match the host architecture, so x64
@@ -213,6 +214,10 @@ compatibility under emulation is not part of these tasks. The aggregate
 commands above on an ARM64 host.
 
 The repository-wide `mise run pre-commit` task is also supported on Windows.
+Run `rust:lockfiles:check`, `sdk:ts:ci`, `go:ci`, and `test:e2e-parity` through
+the Windows-aware tasks when validating those surfaces. Do not count the Go
+Windows ARM64 race-detector exclusion or POSIX permission-bit skips as security
+coverage. SDK test dependencies must remain at their lockfile versions.
 Its Rust check, Clippy, and test dependencies enter the same MSVC environment
 for the native host target and use an inherited compiler wrapper when it is
 available. Linux glibc
@@ -311,12 +316,13 @@ Useful log files:
 | `test-x86_64-pc-windows-msvc-unsupported-*.log` | Focused unsupported-driver contract output. |
 | `test-aarch64-pc-windows-msvc-unsupported-*.log` | Focused native ARM64 contract output. |
 
-The first check builds bundled Z3 from source through `z3-sys`. Cargo stores the
-native build output in its target tree, so the Windows target cache reuses it.
-The resulting release executables do not require `libz3.dll`. The artifact
-report computes SHA256 through .NET directly and does not rely on the
-`Get-FileHash` module being available inside the mise-launched Windows
-PowerShell process.
+The first check downloads the pinned official Z3 archive for the target
+architecture through `z3-sys`. GitHub Actions authenticates the lookup with its
+read-only workflow token; local users can set `READ_ONLY_GITHUB_TOKEN` if an
+unauthenticated lookup is rate-limited. Cargo stores the extracted library in
+its target tree, so the Windows target cache reuses it. The artifact report
+computes SHA256 through .NET directly and does not rely on the `Get-FileHash`
+module being available inside the mise-launched Windows PowerShell process.
 
 ## Common Fix Patterns
 

.agents/skills/build-openshell-mxc-windows/reference.md

@@ -68,11 +68,11 @@ file.
 For ARM64, verify the Visual Studio instance contains the ARM64 MSVC tools,
 ARM64 Spectre-mitigated libraries, Clang tools, CMake tools, and a Windows SDK.
 Clang supplies host-native `libclang.dll` for `bindgen` and `clang-cl.exe` for
-ARM64 crypto dependencies such as `aws-lc-sys`. Native builds use the normal
-bundled-Z3 CMake path. An x64-to-ARM64 check/build discovers and adds
-host-native Ninja to `PATH`, builds bundled Z3 with native MSVC `cl.exe` and
-the Visual Studio generator, and lets the crypto crates select `clang-cl`. Use
-a short `CARGO_TARGET_DIR` if Windows path-length limits are reached.
+ARM64 crypto dependencies such as `aws-lc-sys`. Native and
+x64-to-ARM64 builds use the official prebuilt Z3 4.16.0 static library for the
+target architecture. An x64-to-ARM64 check/build discovers and adds host-native
+Ninja to `PATH`, while the crypto crates select `clang-cl`. Use a short
+`CARGO_TARGET_DIR` if Windows path-length limits are reached.
 
 ## Unsupported Driver Rules
 
@@ -112,16 +112,18 @@ top-level workspace targets for check/test:
 --exclude openshell-driver-vault
 --exclude openshell-driver-vm
 --exclude openshell-sandbox
---exclude openshell-supervisor-network
+--exclude openshell-supervisor
 --exclude openshell-supervisor-process
 --exclude openshell-vfio
 ```
 
 The gateway keeps platform configuration and unsupported-operation contracts
-without depending on the Docker, Kubernetes, Podman, sandbox supervisor,
-process supervisor, VM, or VFIO runtime crates. The Kubernetes Secrets and
-Vault libraries still compile as gateway dependencies; only their standalone
-Unix-socket binaries and package-level tests are excluded as top-level targets.
+without depending on the Docker, Kubernetes, Podman, sandbox runtime,
+standalone supervisor, supervisor process runtime, VM, or VFIO crates. The MXC
+driver does depend on the cross-platform supervisor network library for its host
+egress proxy. The Kubernetes Secrets and Vault libraries still compile as
+gateway dependencies; only their standalone Unix-socket binaries and
+package-level tests are excluded as top-level targets.
 
 ## Common Errors
 

.agents/skills/helm-dev-environment/SKILL.md

@@ -69,28 +69,15 @@ mise run helm:skaffold:dev
 mise run helm:skaffold:run
 ```
 
-**Supervisor sidecar topology** (build once and leave running):
-```bash
-mise run helm:skaffold:run:sidecar
-```
-
-**Supervisor sidecar topology with TLS/mTLS enabled** (build once and leave running):
-```bash
-mise run helm:skaffold:run:sidecar-mtls
-```
-
-Both commands build the `gateway` and `supervisor` images and deploy the OpenShell Helm
-chart. The sidecar profile renders an `openshell-network-init` init container for
-nftables setup and an `openshell-supervisor-network` runtime sidecar for proxying.
-Binary-aware policy mode runs that sidecar as UID 0 with `SYS_PTRACE` and
-`DAC_READ_SEARCH`; relaxed mode can run it as the configured proxy UID, which
-must be at least `1000` and distinct from the workload UID. The
-sidecar-mTLS profile reuses `ci/values-sidecar.yaml` and restores
-`server.disableTls=false` inline for Skaffold. The `pkiInitJob` hook (a pre-install
-Job that runs `openshell-gateway generate-certs`) generates mTLS secrets on first
-install. The default Skaffold values export gateway and Kubernetes-driver traces to
-the collector service installed by `helm:k3s:create`. Envoy Gateway opt-in; see the
-Optional Add-ons section below.
+The Skaffold flow builds distinct `gateway`, `sandbox`, and `supervisor` images
+and deploys the OpenShell Helm chart. The Kubernetes driver creates a
+capability-free workload Pod and a directly managed capability-free supervisor
+Pod. One namespace-wide NetworkPolicy denies direct egress from every OpenShell
+workload Pod. The
+`pkiInitJob` hook (a pre-install Job that runs `openshell-gateway generate-certs`)
+generates mTLS secrets on first install. The default Skaffold values export
+gateway and Kubernetes-driver traces to the collector service installed by
+`helm:k3s:create`. Envoy Gateway is opt-in; see the Optional Add-ons section.
 
 The gateway Service uses ClusterIP. Access is via Envoy Gateway (port `8080`) or
 the unified local forwarding task:
@@ -102,9 +89,9 @@ mise run helm:k3s:forward
 The task forwards OTLP/gRPC to `http://127.0.0.1:4317` and the trace UI to
 `http://127.0.0.1:18888`. When Skaffold has deployed a Kubernetes gateway, it
 also forwards the gateway to `http://127.0.0.1:8090`; otherwise it continues
-with the collector ports only. A successful plaintext `helm:skaffold:run` or
-`helm:skaffold:run:sidecar` registers the gateway under the worktree-specific
-k3d cluster name and selects it as the active gateway. Keep the forwarding
+with the collector ports only. A successful plaintext `helm:skaffold:run`
+registers the gateway under the worktree-specific k3d
+cluster name and selects it as the active gateway. Keep the forwarding
 task running while using those endpoints.
 
 ### Viewing local traces
@@ -134,8 +121,7 @@ create the Secret named `openshell-ha-pg` with a `uri` key, then run
 ### TLS behaviour
 
 `ci/values-skaffold.yaml` sets `server.disableTls: true`, so Skaffold-based deploys run
-plaintext by default. To test sidecar topology with TLS enabled, use
-`mise run helm:skaffold:run:sidecar-mtls`.
+plaintext by default. Override `server.disableTls=false` to exercise TLS/mTLS.
 
 | Mode | `server.disableTls` | Gateway scheme |
 |------|---------------------|----------------|
@@ -188,12 +174,6 @@ openshell sandbox list --gateway-endpoint https://localhost:8090
 mise run helm:skaffold:delete
 ```
 
-For a sidecar-profile deployment:
-
-```bash
-mise run helm:skaffold:delete:sidecar
-```
-
 ### Delete the cluster entirely
 
 ```bash
@@ -256,15 +236,19 @@ Key Helm values:
 
 ### Keycloak OIDC
 
-One-time setup — only needed once per cluster lifetime:
+Initial setup — rerun it whenever you want to rotate the development CA:
 
 ```bash
 mise run keycloak:k8s:setup
 ```
 
 This deploys Keycloak (`quay.io/keycloak/keycloak:24.0`) into the `keycloak` namespace,
-imports the openshell realm from `scripts/keycloak-realm.json`, and prints a port-forward
-command for acquiring tokens from the CLI.
+imports the openshell realm from `scripts/keycloak-realm.json`, generates a short-lived
+development TLS certificate, and publishes its trust anchor as the
+`openshell-keycloak-ca` ConfigMap in the OpenShell namespace. The command prints a
+port-forward command for acquiring tokens from the CLI. Rerunning setup rotates the
+development certificate and trust anchor; redeploy the gateway afterward so it reloads
+the mounted CA bundle.
 
 Then activate OIDC in the OpenShell Helm chart:
 1. Uncomment `#- ci/values-keycloak.yaml` in `skaffold.yaml`
@@ -288,12 +272,31 @@ SPIFFE JWT-SVIDs for dynamic provider token grants:
 `openshell.local` and adds a `ClusterSPIFFEID` that maps sandbox pod
 annotations to `spiffe://openshell.local/openshell/sandbox/<sandbox-id>`.
 OpenShell mounts the SPIFFE CSI Workload API socket at
-`/spiffe-workload-api/spire-agent.sock` into sandbox pods for provider token
+`/spiffe-workload-api/spire-agent.sock` only into supervisor Pods for provider token
 grants. Supervisor-to-gateway authentication remains on the Kubernetes
 ServiceAccount bootstrap and gateway-minted sandbox JWT path; the selected
 Kubernetes compute driver validates the projected token before the gateway
 mints its JWT.
 
+### Vault Credential Driver
+
+The `credential-driver-vault` Skaffold profile applies
+`ci/values-credential-driver-vault.yaml`. Its external OpenBao/Vault backend
+must expose HTTPS at the configured service DNS name and publish the issuing CA
+certificate as the `ca.crt` key in the `openbao-ca` ConfigMap. Local e2e uses
+OpenBao dev TLS and an `openbao-0` DNS alias matching its generated certificate.
+The Helm value
+`server.credentialDrivers.vault.caConfigMapName` mounts that key into the
+gateway and renders the driver's `ca_bundle` setting. Non-loopback HTTP
+addresses fail gateway startup, and hostname verification requires the service
+DNS name in the server certificate SANs.
+
+```bash
+cd deploy/helm/openshell
+skaffold run -p credential-driver-vault
+kubectl -n openshell logs statefulset/openshell -c openshell-gateway --tail=200
+```
+
 ---
 
 ## Cluster Lifecycle (stop/start)
@@ -349,10 +352,10 @@ for dependencies still declared in `Chart.yaml`.
 | `deploy/helm/openshell/ci/values-gateway.yaml` | Envoy Gateway GRPCRoute + Gateway overlay |
 | `deploy/helm/openshell/ci/values-high-availability.yaml` | HA test overlay (`replicaCount: 2` with external PostgreSQL Secret) |
 | `deploy/helm/openshell/ci/values-keycloak.yaml` | Keycloak OIDC overlay |
-| `deploy/helm/openshell/ci/values-sidecar.yaml` | Supervisor sidecar topology overlay for Kubernetes e2e/dev |
 | `deploy/helm/openshell/ci/values-spire.yaml` | SPIFFE/SPIRE provider token grant overlay |
 | `deploy/helm/openshell/ci/values-spire-stack.yaml` | SPIRE hardened chart values for local dev |
 | `deploy/helm/openshell/ci/values-tls-disabled.yaml` | Lint-only: TLS + auth disabled (reverse-proxy edge termination) |
+| `deploy/helm/openshell/ci/values-credential-driver-vault.yaml` | Vault credential-driver validation overlay with HTTPS and private-CA trust |
 | `deploy/kube/manifests/envoy-gateway-openshell.yaml` | GatewayClass for Envoy Gateway (`mise run helm:gateway:apply`) |
 | `tasks/scripts/helm-k3s-local.sh` | k3d cluster create/delete/start/stop/status |
-| `tasks/scripts/keycloak-k8s-setup.sh` | Keycloak deploy + realm import |
+| `tasks/scripts/keycloak-k8s-setup.sh` | Keycloak deploy, realm import, and development TLS trust anchor |