Marketplace deployers: hardening follow-ups from the mongodb PR review (netpol upsert dedup, container securityContext, stale-Secret reuse) #197

Context

Follow-ups surfaced by the QA and Security reviews of nan-cloud-api#370 (private MongoDB marketplace kind) that are deliberately OUT of that PR's scope. All three apply to the deployer family, not just mongodb.

Follow-ups

1. Deduplicate upsertNetworkPolicy — deployers/mongodb.go and deployers/postgres.go carry line-for-line copies of the same upsert/converge helper, and it is the security-relevant netpol convergence path: a fix to one copy will not reach the other. Extract one package-level upsertNetworkPolicy(ctx, clientset, desired) used by both, and add a fake-clientset PrependReactor("create", "networkpolicies", AlreadyExists) test covering the create-race branch (currently untested for mongo).

2. Container hardening for all marketplace deployers — mongodb/qdrant/chromadb StatefulSets set no securityContext (allowPrivilegeEscalation: false, capabilities.drop: [ALL], runAsNonRoot) and no automountServiceAccountToken: false. Pre-existing gap, now visible in three kinds. Note: the official mongo entrypoint starts as root and drops to uid 999 via gosu, so runAsNonRoot needs runAsUser: 999 (and the existing pod fsGroup: 999 stays).

3. Secret reuse on partial destroy — if Destroy fails after deleting PVCs but before deleting the auth Secret, a re-install with the same app name reuses the old password, which mongod (initdb-only) ignores → member locked out of their own DB (no exposure; same failure shape as qdrant/chromadb). Option: regenerate the Secret when its nan.builders/marketplace-app-id label does not match the installing AppID.

Acceptance

• Single shared netpol upsert + race test
• securityContext/automountServiceAccountToken applied to all three stateful kinds, tests updated
• Stale-Secret regeneration policy decided and implemented or explicitly rejected with rationale