fix(scanners): own copied pull-secrets at create time so they GC with the Job

[mayankpande88]

Description

Copied image-pull secrets (imgps-*) were leaking: they accumulate in the scanner namespace and never get cleaned up.

Root cause

The copy flow created each Secret without an ownerReference, then tried to attach one via a post-create Secret Update (ownReferencedSecrets). But the runner ServiceAccount has create on secrets and not update/delete. Additionally, the ownerReference set BlockOwnerDeletion: true, which the GC admission plugin only allows if the caller has update on the owner's finalizers subresource (jobs/finalizers) — which the agent also lacks. So the Update was rejected (403) and, being best-effort, silently dropped. Result: every copied secret was orphaned with no ownerReference, so neither the Job's TTL nor the reaper ever garbage-collected it.

(Confirmed on a live cluster: kubectl auth can-i update secrets → no, update jobs/finalizers → no; observed imgps-* secrets with empty ownerReferences.)

Fix

Stamp the ownerReference at Secret create time (needs only create, which the agent has). Since the reference needs the Job UID and the pod must not pull before its credentials exist:

1. Resolve the pull secrets (read source, build the copy objects — don't create).
2. Create the Job suspended, referencing the not-yet-created copies on its pod.
3. Create the copies owned by the Job.
4. Resume the Job (patch spec.suspend=false — patch on jobs is already granted).

BlockOwnerDeletion is dropped (unnecessary for GC, and avoids the jobs/finalizers requirement). If resume fails, the Job is deleted so its owned copies GC with it instead of lingering.

No RBAC/chart change, and no expansion of the agent's secret permissions (a customer-deployed agent stays at create-only on secrets).

Testing

• Unit test (TestAutoCopyPullSecrets_CopiesRegistrySecretsAndAttaches): asserts each copy is Job-owned and the Job is not left suspended.
• Integration test against a real apiserver (TestPrimitives_RealAPIServer/ScheduleJob_AutoCopyPullSecrets): confirms the copy is owned by the Job end to end. Both pass; go build ./..., go vet, gofmt clean.

Notes

• Non-pull-secret scans are unchanged: the Job is only suspended when there are pending copies to create.
• Pairs with the api-server manual-scan tenant fix and the SCANNER_AUTO_COPY_PULL_SECRETS enablement (separate PRs) that make private-image scans work in the first place.

[gemini-code-assist]

Code Review

This pull request refactors the Kubernetes Job creation flow to safely handle image-pull secrets. Instead of copying secrets beforehand, the Job is created in a suspended state, the copied secrets are created with the Job's UID as the owner reference, and then the Job is resumed. A review comment points out a critical issue in the error handling path: if resuming the Job fails due to context cancellation or timeout, the cleanup Delete call will also fail because it uses the same cancelled context. It is recommended to use a non-cancelled context (such as context.WithoutCancel(ctx)) for the cleanup deletion and log any failures.