feat: add Helm chart for Kubernetes deployment

[Tsukikage7]

Which issue or RFC does this PR close?

Related to #1609.

Rationale for this change

PowerContext supports separate API and background processes with OceanBase, but deploying them on Kubernetes requires operators to assemble their own manifests and upgrade procedure. This adds a Helm chart and deployment guide for the current runtime.

What changes are included in this PR?

• Add a chart for API and background Deployments, an API Service, optional Ingress, existing Secret references, resources and API health probes.
• Require an explicit application image tag or digest, enable bearer authentication and enforced Access, and share the cursor key across API replicas.
• Use stateless MCP and the global database lease for background leadership. Document background monitoring and coordinated upgrades with offline migration when required.
• Add English and Chinese deployment guides, rendering/configuration tests in the Main workflow, and an opt-in cluster check for authentication, persistence after Pod replacement and lease takeover.

Are there any user-facing changes?

Operators can deploy the current api and background roles against an externally managed OceanBase database. Chart version 0.1.0 requires an explicitly supplied application image and existing Secrets. Background replicas are standby candidates for one active supervisor; background health must be checked through lease renewal, logs and processing progress.

Cold-start acceptance depends on a separate runtime initialization fix for concurrent DDL and authorization bootstrap. The tested image contains that local fix; it has not been committed or published. This dependency must be integrated separately before the cold-start result applies to a released image.

How was this change tested?

• uv run --locked --extra server pytest tests/test_helm_chart.py tests/test_helm_acceptance.py -q — 22 passed. Tests render real Helm YAML, parse role settings, check Secret references and reject unsupported configuration; simulated CLI tests preserve preflight and per-Pod checks.
• helm lint deploy/helm/powercontext --strict --set image.repository=example/powercontext --set image.tag=ci --set existingSecret=credentials — passed, also with --values deploy/helm/powercontext/values-acceptance.yaml.
• make check and git diff --check — passed.
• Release-name regressions for true, false, on and off failed before the fix and pass after quoting. Parsed metadata and Pod labels and selectors remain strings; Deployment selectors match Pod labels and the Service selects only API Pods.
• python tests/e2e/helm_acceptance.py --namespace pc-fts-acceptance-20261005 --release pc-acceptance — the existing isolated RKE2/OceanBase run verified authenticated HTTP/MCP, unauthenticated 401 responses, persisted Scope readback from both replacement API Pods, and background lease takeover with generation 1→3. For the pc-acceptance release, before/after manifests parse identically with the acceptance profile. Label typing was revalidated locally without repeating cluster acceptance.

Cluster evidence uses Kubernetes v1.35.7+rke2r1, Helm 3.19.0, OceanBase CE 4.4.2.1 and the local test generation model. The database started with zero tables; initial and replacement application containers had zero restarts. Disposable resources were removed after validation.

Application base: 86537e4fbe2f3bec2d0a93c73caea4ec8ebaec24; runtime patch SHA-256: 3b38b98cd3df3cbe806d14bb8bb927ac61a0d07943f820a25ed14e8b1fcadda1. Local image: powercontext-fts-fix:86537e4f-20261005-v3, ID sha256:c95925cebba951d9ded320cc887eef9cc8ed0d35a768b7859d1f2b211336d6dd. This ID identifies the local image, not a published registry manifest.

[Tsukikage7]

@AlexStocks, could you take an initial look at the chart scope and the current api/background deployment with external OceanBase?

The added CI job installs Helm, runs strict lint for the default and acceptance profiles, and runs quick rendering/configuration and acceptance-script unit tests. It does not run a real cluster. The workflow runs are currently awaiting maintainer approval (action_required).

This remains a draft because the concurrent DDL and authorization initialization fixes need to land separately. Feedback on the deployment design and scope would be helpful while that dependency is being prepared.