ops: safe standalone Kubernetes manifests with Recreate rollout (#47) - #202

Only an Ingress example existed; users wrote every other manifest by hand,
and the documented Deployment used the default RollingUpdate, which starts
the new pod while the old one still owns the volume.

deploy/kubernetes now ships a Kustomize base (StatefulSet, PVC, Service,
ConfigMap), an optional ingress-nginx Component, a per-tenant overlay and
a maintenance pod for backup and restore:

- One replica on a StatefulSet: an update deletes inputlayer-0 and waits
  for it to terminate before creating the replacement, so the old and new
  engine never overlap. The data-dir LOCK refuses a second writer on the
  same node; ReadWriteOnce stops a second node. The docs name the cases
  none of this covers (force delete, partitioned node, multi-attach or
  NFS storage) and the Deployment rule (strategy: Recreate).
- Restricted Pod Security: uid/gid/fsGroup 999, read-only root
  filesystem, no capabilities, RuntimeDefault seccomp, no service account
  token, and no service links (they inject INPUTLAYER_* variables).
- The maintenance pod holds the engine's own LOCK with flock(1), so it
  cannot run beside an engine and an engine cannot start beside it.

The Dockerfile pins the engine user to uid/gid 999, the uid the image
already had. scripts/check-k8s-manifests.sh (make k8s-check) renders and
validates the manifests with kubeconform and checks the replica count and
uid. The deployment guide documents install, security, configuration
precedence, probes, upgrades and a backup/restore runbook; the probe and
Ingress snippets elsewhere now point at the shipped files.

Deployment only: no change under src/ or to Cargo files.

Closes #47