Adds oci-javascript-mcp-server Kubernetes/Kata Isolation Provider

[dustin-sale]

Description

Extends the existing oci-javascript-mcp-server with a Kubernetes isolation provider while preserving Podman as the default. Provider and profile selection are trusted startup configuration, use exact accepted values, and fail closed without falling back to another runtime or credential source.

The Kubernetes provider includes:

• Explicit local-development, in-cluster, and kata-in-cluster profiles behind a shared isolation-provider interface.
• A fresh, credential-free Kubernetes pod for each JavaScript execution, connected to the trusted host over a bounded framed exec channel while OCI credentials and SDK clients remain on the host.
• Fixed non-root pod security settings, disabled service-account token mounting and service links, bounded memory-backed temporary storage, and reviewed CPU, memory, and ephemeral-storage ranges.
• Startup preflight checks for namespaces, exact RBAC permissions, admission-policy behavior, image digest pinning, and the Kata RuntimeClass and handler where applicable.
• Fail-closed lifecycle handling with absolute deadlines, cancellation, bounded cleanup tails, concurrent channel shutdown and zero-grace pod deletion, and deletion confirmation.
• A cleanup-only reconciler for expired managed pods with separately constrained permissions and per-candidate time bounds.
• Hardened worker-channel validation and budgets for framing, RPC IDs, messages, logs, results, concurrency, egress, and transport backpressure.
• Versioned standard Kubernetes and Kata manifests, container build assets, an OCI session-secret synchronization helper, local dry-run tooling, OpenSpec artifacts, deployment guidance, and security limitations.
• Fake-API, provider, lifecycle, cancellation, reconciliation, hostile-channel, manifest, configuration, and optional real-cluster tests across all three profiles.

The motivation is to support cluster-managed execution and an optional Kata-backed deployment profile without weakening the server's trusted-host boundary or changing existing Podman deployments. The standard Kubernetes profiles provide container isolation only. The Kata profile is intentionally documented as a proof of concept and still requires deployment-specific runtime evidence and a current security review before it can be treated as a VM-grade boundary.

The implementation adds @kubernetes/client-node and its WebSocket type support. Kubernetes deployments require access to a compatible cluster, the documented namespaces and RBAC/admission/network controls, a digest-pinned runner image, and a reviewed Kata RuntimeClass for kata-in-cluster. The credential synchronization helper additionally requires Python 3 and an existing OCI CLI configuration. Podman remains the default and gains no new Kubernetes dependency at runtime. No downstream module changes are required.

Additional unit-test coverage identified and corrected four behavior defects:

• Kubernetes readiness now requires an observed Running pod. Normal watch EOF
  fails closed, and the initial readiness GET and watch both respect
  cancellation and the absolute execution deadline.
• OCI authentication selection now follows SDK profile inheritance, including
  named profiles that inherit a DEFAULT security-token path and profiles that
  explicitly override or clear that value.
• Final JavaScript expression results are preserved when followed by comments,
  with regression cases for strings, templates, regular expressions, postfix
  division, and JavaScript line terminators.
• discover_oci examples now represent required array fields as arrays,
  including model arrays, while retaining bounded model expansion.

The suite also verifies concurrent RPC response correlation with reversed
replies and mixed success/failure outcomes, plus background reconciliation's
immediate execution, prevention of overlapping cycles, recovery after failure,
and idempotent stop behavior. These tests use fake APIs and controlled responses.
The RPC protocol and reconciliation shutdown contract are unchanged.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Run the following from src/oci-javascript-mcp-server:

• npm run check — TypeScript validation passed.
• npm run packcheck — npm package dry-run verification passed.
• npm run check:kubernetes-manifests — all 14 standard and Kata Kubernetes manifest tests passed.
• git diff --check 6633b602248bf44dbaf9aebe2e584c4a53622f1a...HEAD — passed with no whitespace errors.
• npm run ci — 184 tests passed with 95.39% coverage

Additionally, I tested in both local-development and in-cluster kubernetes isolation provider profile modes.

Latest whole-server validation, run from the repository root:

• moon run --no-actions oci-javascript-mcp-server:check oci-javascript-mcp-server:test
  — native setup, protobuf compilation, TypeScript checking, and the c8 test
  task passed.
• 326 tests passed, 6 skipped, 0 failed.
• Aggregate coverage: 95.75% statements, 91.29% branches, 95.58% functions,
  and 95.75% lines. All configured 90% coverage thresholds passed.
• The four behavior fixes have regressions demonstrated failing before the
  corrections and passing afterward. Additional review regressions cover
  late readiness events and JavaScript source-preservation edge cases.
• git diff --check passed.

--no-actions bypassed dependency setup/synchronization after npm dedupe
stalled; compilation, checking, tests, and coverage enforcement still ran.
These results validate the installed dependency environment. Fake API tests
do not establish real-cluster runtime or admission-policy behavior.

Test Configuration:

• Firmware version: Not applicable
• Hardware: Apple Silicon (arm64)
• Toolchain: macOS 26.6.2; Node.js 22.14.0; npm 11.18.0; TypeScript 5.9.3
• SDK: oci-sdk 2.132.x; @kubernetes/client-node 2.x; @modelcontextprotocol/sdk 1.29.x

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules