Helm --atomic --timeout cancellation and rollback boundaries

A deployment policy is needed for Helm upgrades that combines --timeout with --atomic to provide a bounded wait for readiness and an automatic rollback on failure.

The documented behavior indicates --timeout limits client wait time and --atomic triggers a rollback on timeout or failure, while a SIGINT stops the client immediately. It is unclear how these mechanisms interact when cancellation occurs before the timeout expires, and whether server-side reconciliation continues independently of the client process.

The goal is to define a consistent cancellation boundary and rollback guarantee without assuming client-side state.

Does --atomic initiate a rollback when the Helm client is interrupted by SIGINT? What state can Kubernetes resources be left in if the client exits before the timeout elapses? Is rollback initiation considered client-side or server-side?