fix(operator): run the operator as a non-root, read-only container (#297 part 1)

[v0l]

Part 1 of #297 (non-root runtime + securityContext). Parts 2 (scoped RBAC) and 3 (dedicated DB credentials) follow as their own PRs.

• Dockerfile — USER 65534:65534 on the lnvps-operator stage only. uid 65534 is nobody in debian:trixie-slim, the runtime base.
• lnvps_operator/k8s-minimal.yaml — pod runAsNonRoot/runAsUser/fsGroup 65534, container allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities: drop: ["ALL"].
• lnvps_operator/README.md — a "Runtime hardening" section. The README already claimed non-root and read-only under Monitoring; now it is true.

Nothing in the operator writes to its own filesystem: the only std::fs write path in lnvps_operator/src is the encryption key file, and only when encryption.auto-generate is set (lnvps_operator/src/main.rs:159 -> lnvps_db/src/encryption.rs:54). That option cannot work under readOnlyRootFilesystem, and a generated key would not match the API's anyway — the README now says to use LNVPS_ENCRYPTION_KEY or a read-only Secret mount, which is what the manifest already does. The config is a read-only ConfigMap mount.

No test: this is the example manifest and the image definition, neither of which is what the cluster runs. Verified uid=65534(nobody) exists in debian:trixie-slim and that the manifest parses with both securityContexts on the right objects. cargo test --workspace unchanged and green (lnvps_e2e aside, which needs live services).

Merging changes nothing in the cluster — the running operator picks this up when its image is rebuilt and the Deployment is re-applied, and per #295 the live install does not come from this manifest. Kieran's call on how it is rolled out.

Channel: lnvps (f5894ea9-44c7-56fb-bd9b-6e3e671e4bc1)