[Chore]: capture goroutine dumps from CNPG pods when an e2e test times out

What problem is this going to solve? When an e2e spec hangs and hits the suite timeout, we only get a snapshot of Kubernetes resources at the very end, once everything is already dead. There's no visibility into what the process inside the pod was actually doing while it was stuck. Root-causing this kind of hang means either catching it live with cluster access while it's happening, or hoping it recurs, which isn't guaranteed.

This came up investigating a "cluster-restore never becomes ready" hang in the GKE upgrade suite: the pod sat wedged for over two hours with no crash and no log output, and by the time anyone could look, the process had already been killed by teardown.

Describe the solution you'd like Before a stuck test's namespace gets torn down, send SIGQUIT to every container, init and regular, in every CNPG-managed pod in that namespace. Go's default handling for SIGQUIT dumps every goroutine's stack to stderr and exits, which lands in the pod's own log and gets swept into the failure artifacts we already collect. No live access needed at the time of the hang. This should only fire for specs that actually got stuck (timeout, interrupted, aborted), not for every ordinary assertion failure.

Describe alternatives you've considered Watching CD runs live to catch a hang in time to exec in manually. Not practical: these run unattended and a given hang isn't guaranteed to happen again.

Backport? Yes, it's a debugging tool.

Are you willing to actively contribute to this feature? Yes