fix(k8s): custom-stack VPA targets a non-existent (double-suffixed) deployment

[Cre-eD]

Bug

For custom stacks (parentEnv != stackEnv), the VPA never right-sizes the pods because it targets a deployment that doesn't exist.

DeploySimpleContainer already applies the parentEnv suffix to Service/Deployment (e.g. myapp → myapp-tenant-a). NewSimpleContainer then re-derived baseResourceName via generateDeploymentName on the already-suffixed name → myapp-tenant-a-tenant-a. Since baseResourceName names the VPA (resource name and spec.targetRef.name) and the HPA, the VPA's targetRef pointed at a non-existent myapp-tenant-a-tenant-a Deployment. The Deployment itself is correct (it uses sanitizedDeployment), so the mismatch was silent — the VPA simply applied no recommendation and pods stayed pinned at the base request.

Non-custom stacks are unaffected (no suffix is applied upstream, so the names already matched).

Fix

-	baseResourceName := generateDeploymentName(sanitizedService, args.ScEnv, parentEnv)
+	baseResourceName := sanitizedDeployment

The only caller (DeploySimpleContainer) already made the name parentEnv-aware, so re-deriving it was the bug.

Blast radius

On the next deploy of a custom stack, Pulumi replaces the VPA and HPA (old double-suffixed logical names removed; correctly-named ones created). The HPA's scaleTargetRef already used the real Deployment object, so scaling is unaffected by the rename. This fixes previously-orphaned VPAs on all custom stacks.

Scoped intentionally: the configmap/secret/image-pull-secret names stay double-suffixed for custom stacks — they're self-consistent (the pod references the same generated names), so they keep working. Renaming them is a separate migration with a pod-rollout cost and isn't needed for this fix.

Test

Test-first regression (TestNewSimpleContainer_CustomStackBaseNameNotDoubleSuffixed): replicates the production caller contract (pre-suffixed Service/Deployment for a custom stack) and asserts baseResourceName is single-suffixed via the HPA (which shares it with the VPA). Confirmed it fails on the bug and passes with the fix; full pkg/clouds/pulumi/kubernetes suite green.

[github-actions]

Semgrep Scan Results

Repository: api | Commit: a54b80b

Check	Status	Details
⚠️ Semgrep	Warning	1 warning(s), 1 total

Scanned at 2026-06-21 14:06 UTC

[github-actions]

Security Scan Results

Repository: api | Commit: a54b80b

Check	Status	Details
✅ Secret Scan	Pass	No secrets detected
✅ Dependencies (Trivy)	Pass	0 total (no critical/high)
✅ Dependencies (Grype)	Pass	0 total (no critical/high)
📦 SBOM	Generated	522 components (CycloneDX)

Scanned at 2026-06-21 14:06 UTC

[Cre-eD]

Hardened after a 4-way review (2 subagents + codex + gemini):

• Strengthened the test to capture the VPA directly (the VPA registers under kubernetes:autoscaling.k8s.io/v1:VerticalPodAutoscaler, not the generic CustomResource token — added that case to the test mock) and assert its spec.targetRef.name is single-suffixed, instead of inferring it via the HPA.
• Documented the caller pre-suffix contract on NewSimpleContainer so this can't regress.
• Reviewers confirmed: orphan double-suffixed VPA/HPA are cleanly deleted on redeploy (no RetainOnDelete/aliases on VPA/HPA — only the Namespace has them), the left-double-suffixed secrets/configmaps are self-consistent (safe to leave), and there's no P0. Rollout note: this churns VPA/HPA for every custom stack on its next deploy, so it'll be staged (one stack first, verify the plan is exactly delete-old/create-new).

[github-actions]

📊 Statement coverage

Measured on the documented included set (see docs/TESTING.md → Coverage scope). Observe-only — no regression gate is enforced yet.

Scope	This PR	main baseline	Δ
Included set (Gold-tier denominator)	90.3%	90.3%	+0.0 pp
Full set (whole repo, transparency)	27.6%	27.7%	-0.1 pp

Baseline: main @ 6d0d0cb