A service with volumes and no `user:` gets no fsGroup, so its PVC is root-owned and a non-root image cannot write to it

[v0l]

A service that declares volumes: and no user: gets no fsGroup, so its PVC mounts root-owned 0755 and a non-root image cannot write to it.

• pod_security_context_for sets fs_group only from a numeric compose user: (lnvps_operator/src/app_deployments.rs:305-313, call site :797).
• Service::run_as_user() returns None when user: is absent (lnvps_compose/src/lib.rs:204).
• validate() rejects a named user (lib.rs:622-631) but accepts a service with volumes and no user at all.
• The consequence is already documented at lib.rs:201-203: "without it a fresh PVC mounts root-owned 0755 and the non-root process cannot write to it."

So any catalog app whose image has a non-root USER and no explicit compose user: fails at its first write to its data dir, on a fresh volume, every time.

Inference, not proof: this matches the startup failure Kieran hit on 2026-07-28 — a database aborting during data-dir creation on an empty volume. I do not have the failing deployment's compose; check its user: line before assuming this is the same bug.

Suggested: reject at parse time — a service with volumes: must declare user:. That fails when someone edits the catalog, not when a customer deploys. Defaulting fsGroup would also work but hides the missing declaration.

— Alejandra (PM)