skip the PodListeners lookup when the served Pod is being deleted

Problem

The secret-operator needs to read PodListeners in order to retrieve additional listener addresses to generate into the SAN field of certificates it creates. It has a long timeout waiting for these objects to appear, when a pod is spawned and requests the listener scope on certificates.
Especially during namespace deletion (maybe at other times as well) this can become a problem, when the PodListeners get deleted and the secret operator waits for them indefinitely. Since this is part of the NodePublishVolume step, this results in the Pod being stuck and holding pvc-protection.

Fix

In NodePublishVolume, if the Pod the volume serves has a deletionTimestamp, skip the
PodListeners lookup and issue the (throwaway) certificate without listener SANs so the mount can
complete. A Pod that is being deleted does not need listener-addressed certs.

The startup/steady-state path is unchanged: live Pods still wait for their listener addresses, so no
correctness regression and no startup race, the guard only relaxes behaviour for Pods already
marked for deletion.

Inizia dal punto di ingresso NodePublishVolume e traccia come vengono gestiti deletionTimestamp del Pod servito e PodListeners prima della generazione del certificato. Verifica la ricerca esistente di PodListeners e il percorso del certificato, quindi conferma che i Pod eliminati saltino la ricerca, mentre i Pod attivi mantengano il comportamento attuale e il mount venga completato senza SANs dei listener.