feat(deploy): add k3s deployment foundation and complete offline images

Introduce a self-contained kustomize stack under deploy/k3s covering
namespace, config, placeholder secrets, infra StatefulSets, app
Deployments/Services, migration and minio-init Jobs, and Traefik
Ingress for both tenant and ops hosts. Add Dockerfile.ops-web so the
operations frontend can ship as an nginx image, and extend the offline
package script to build and bundle ops-api, kol-assist-worker, and
ops-web alongside the k3s manifests. Wire the new ops/security knobs
through .env.example and the compose stack.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

findings.md

@@ -216,3 +216,15 @@
 - Daily plan loading follow-up: `loadDailyMonitoringPlans` no longer uses one SQL statement for lease-aware client election and platform JSON aggregation. It first selects the primary client candidate per `(tenant_id, workspace_id)` with subscription policy and lease preference, then batch-loads authorized platform JSON for the selected `(tenant_id, workspace_id, client_id)` tuples. If authorization disappears between reads, the candidate is skipped rather than producing an empty executable plan.
 - Authorization bug fix: monitoring authorization now means a bound, non-deleted platform account for a supported AI platform. `platform_accounts.health` is treated as execution state, not authorization state, so non-live accounts no longer suppress daily scheduled task generation, dashboard authorization, desktop task targeting, or question-detail history display.
 - Immediate collection remains stricter than daily scheduled collection: it still requires the target desktop client to be online, and the target client is now the same client that owns the authorized platform accounts. Daily scheduled collection still materializes backend tasks while the desktop client is offline and dispatches when the client becomes available.
+
+## k3s Deployment Foundation - 2026-04-30
+- The existing deploy topology is a good base for k3s: app services are `tenant-api`, `worker-generate`, `scheduler`, `ops-api`, and `frontend`; repo runtime also contains `kol-assist-worker` and `ops-web`, so the k3s stack includes them too.
+- The stateful dependencies needed for a self-contained k3s install are `postgres`, `monitoring-postgres`, `rabbitmq`, `redis`, `qdrant`, and `minio`.
+- `deploy/k3s` now uses kustomize and renders a namespace, config map, placeholder secret, infra StatefulSets, one-shot `migrate` and `minio-init` Jobs, app Deployments/Services, and Traefik Ingress rules for `geo-rankly.local` and `ops.geo-rankly.local`.
+- Kustomize cannot reference files above `deploy/k3s` under its default load restrictions, so the k3s overlay now carries its own `config/config.yaml`, `config/prompts.yml`, and `config/ops-config.yaml`.
+- Tenant services mount `/app/configs/config.yaml`, `/app/configs/prompts.yml`, and secret-backed `/app/configs/config.local.yaml`, allowing sensitive overrides without rebuilding images.
+- `ops-api` currently reads a single ops config file and does not merge an `ops-config.local.yaml`, so k3s documentation calls out that database password changes must also be reflected in `deploy/k3s/config/ops-config.yaml`.
+- The existing offline package script did not build `ops-api`, `kol-assist-worker`, or `ops-web`; it now builds and saves those images so k3s can run the full service set.
+- `Dockerfile.ops-web` now builds the operations frontend and serves it through its existing nginx proxy to `ops-api`.
+- Verification succeeded with `kubectl kustomize deploy/k3s`, local YAML parsing of 30 rendered Kubernetes objects, `bash -n` for deploy scripts, `git diff --check`, `pnpm --filter ops-web build`, and `pnpm --filter admin-web typecheck`.
+- Live `kubectl apply --dry-run=client` validation could not complete locally because the configured kube-apiserver at `127.0.0.1:26443` is not running; run that validation on the target k3s node.