fix(e2e): resolve Deployment name by label for scale-to-zero test

[hardengl]

Summary

• The k8s-container-service-provider switched from Name to GenerateName for Kubernetes Deployments (PR #22, merged Apr 28)
• The scale-to-zero E2E test assumed the Deployment name matched the container metadata.name, but GenerateName appends a random suffix — so oc scale deployment <name> fails with exit code 1 (not found)
• This has broken flightpath-dcm-nightly for 10 consecutive builds (#71–#80, Apr 30 – May 6). 73/74 tests pass; only this one fails.

Changes

1. sp_helpers_test.go — Added findDeploymentName() helper that resolves the actual Deployment name via label selector dcm.project/dcm-instance-id=<containerID>. Also added error logging to runKubectl so future failures show the actual kubectl output in the Ginkgo report (previously discarded, showing only a bare exec.ExitError with Stderr: nil).
2. sp_container_status_test.go — Updated the "scaled to zero" test to resolve the real Deployment name before scaling, instead of assuming it matches the container name.

Root Cause

In convert.go:313 of k8s-container-service-provider:

// Before:
Name: spec.Metadata.Name,
// After (PR #22):
GenerateName: spec.Metadata.Name + "-",

When a container named e2e-scale-123456 is created via the DCM API, the actual K8s Deployment is named e2e-scale-123456-xK7m2 (random suffix). The test ran oc scale deployment e2e-scale-123456 which doesn't exist.

Test plan

• Run flightpath-dcm-nightly and verify the scale-to-zero test passes (73 → 74/74)
• Verify other cluster-level tests (label filtering, delete lifecycle) are unaffected
• Confirm findDeploymentName correctly resolves via dcm.project/dcm-instance-id label

Attribution

• Requested by: gharden (Slack: <@UTKKVT884>)
• Channel: #ocp-edge-qe

Fixes: FLPATH-4167

🤖 Generated with Claude Code