feat: add a Helm chart and Kubernetes deployment guide

Feature description

I'd like to deploy PowerContext in an existing Kubernetes cluster with an external OceanBase database, so multiple applications and agents can share the service over HTTP and MCP.

Could we add a maintained Helm chart, a deployment guide, and tests for the supported topology? I'm happy to work on this.

Problem and proposed solution

PowerContext already has a Dockerfile, authentication, health endpoints, and support for separate API and background roles with OceanBase. The missing piece is a documented Kubernetes setup that ties these together.

Today, operators need to write their own manifests and work out which roles and replica counts are supported, how to monitor background processes, and how to handle upgrades and migrations.

I propose starting with:

• A Helm chart with the required workloads and Services, external OceanBase configuration, existing Secret references, resource settings, and optional Ingress.
• Health probes and metrics access for each role, including background processes when deployed separately.
• Pinned image versions and documented chart/application compatibility.
• Installation and upgrade instructions, including any steps that require stopping background processes or pausing writes.
• Deployment tests covering authenticated HTTP and MCP access, persistence, and recovery after Pod replacement.

For a supported multi-replica setup, the tests should also cover HTTP and MCP requests reaching different API instances, plus recovery after an active background instance exits. Accepted work should eventually complete without duplicate persisted results or skipped work caused by incorrect cursor advancement.

The chart would connect to an existing OceanBase instance; it would not install or manage OceanBase. Any SQLite example should be limited to evaluation and enforce the single-process restriction.

Alternatives considered

Maintaining manifests outside the project works for individual deployments, but makes it harder to keep configuration and upgrade procedures in sync with PowerContext releases.

Docker Compose is useful for local testing and single-host deployments, but it doesn't cover deployment into an existing Kubernetes cluster.

I'd keep the first version small. An operator and autoscaling can wait until there is a concrete need.

Additional context

Related work:

• #1430 — Distributed Server and background worker support
• #1446 — Database-backed distributed work runtime
• #1421 — Export, backup, and restore

A few deployment references:

• Hindsight API deployment and worker StatefulSet: separate API and worker workloads, with per-role probes and configuration.
• OpenViking Helm chart: a single-instance deployment with persistent storage, configuration, and an explicit replica limit.

These are useful references for packaging and configuration. PowerContext's deployment topology and upgrade procedure should follow its own runtime and storage constraints.

I see @thunguo has been working on #1446. Before starting, I'd like to agree on whether the chart should use the current api/background roles or target the API/Scheduler/Worker roles proposed in that PR.

I can take on the chart, documentation, and deployment tests, and coordinate with the runtime work in #1430 and #1446. Any runtime bugs found during testing can be handled in separate PRs.

Could a maintainer assign this issue to me if this scope makes sense? I'm also happy to write an RFC first if needed.

Are you willing to contribute to this feature?

• Yes, I am willing to contribute code, docs, or design feedback.