Propagate caller cancellation to active Helm uninstall and list requests #296

Summary

Active Kubernetes requests made by Helm uninstall and list operations do not honor the caller's context. A stalled request can continue after the caller cancels the operation.

This issue predates PR #295. At its base revision, dfa8423deccc9cb42a8d78a226264c82814c9209, newActionConfig did not propagate HelmCtx.Ctx into Kubernetes requests. doUninstall called uninstall.Run, and doListByPrefix called list.Run. PR #295 replaces HelmCtx with context.Context but preserves this behavior. The retry helper checks cancellation during retry waits, not during active requests.

Required changes

In internal/helm/helm.go:

• Update newActionConfig and the doUninstall and doListByPrefix call paths so active Kubernetes requests honor caller cancellation and deadlines.
• Use a context-aware Kubernetes client or request transport where Helm's action API does not accept a context. If request timeouts are used, derive them from the caller's deadline and document any remaining cancellation limitation.
• Stop retries when the caller's context is canceled or expires.
• Preserve uninstall's not-found handling and list's prefix filtering.

Returning early from a goroutine without canceling the underlying request is not sufficient.

Acceptance criteria

• A test with a stalled Kubernetes request verifies that canceling the caller's context stops the in-flight request for both uninstall and list.
• A caller deadline bounds active requests.
• Cancellation or deadline expiry does not trigger another attempt.
• Normal uninstall, not-found uninstall, prefix filtering, and transient-error retry behavior remain intact.

Context

Requested by @mclasmeier as a follow-up outside the logger refactor.

• PR: ROX-37174: Replace custom logger with slog-based implementation #295
• Review discussion: ROX-37174: Replace custom logger with slog-based implementation #295 (comment)