Base Kubernetes manifests for api, scheduler and worker

[FullFran]

Base manifests for the three runtimes. No Helm yet — plain YAML first, so the
primitives are understood before they are abstracted away.

Scope

• Deployment for api — replicas, resource requests/limits, probes
• Deployment for worker — starts at 1 replica, autoscaled later
• CronJob or Deployment for scheduler — decide and write down why.
  A CronJob gives Kubernetes-native scheduling but requires the scheduler
  to be idempotent and to stop owning its own timing loop
• Service (ClusterIP) for api
• ConfigMap for non-secret configuration
• Secret for database URL, Redis URL and API keys — never baked into the image
• Job for npm run migrate, run as a pre-deploy step
• securityContext: non-root user, read-only root filesystem, dropped capabilities
• PodDisruptionBudget for api

Notes

Resource requests are not a formality: they are what the scheduler uses for
bin-packing, and getting them wrong is the usual reason a cluster is both
expensive and slow. Set them from measured usage, not from a guess.

The migration Job ordering matters. Decide explicitly whether migrations run
before the new version starts, and what happens on rollback.

Definition of done

kubectl apply -k brings the whole stack up on a local kind or k3s cluster and
the smoke suite (smoke:stack:run) passes against it.