Fix informer delete handling

[27rohan]

Summary

When Kubernetes tells the operator that something was deleted, the notification sometimes arrives in an unexpected wrapper format. The operator's code didn't handle that case and would crash.

This PR teaches the code to unwrap both formats safely — and if the notification is garbage, it just logs an error instead of crashing. Tests were added to cover all these cases.

Why this is needed

client-go may wrap a deleted object in DeletedFinalStateUnknown when a watch deletion is missed and a subsequent relist discovers that the cached object is gone. The existing handlers use bare type assertions, so receiving this valid client-go payload panics the operator.

This exact failure has occurred in released versions of the upstream operator:

• panic: interface conversion: interface {} is cache.DeletedFinalStateUnknown, not *v1.Pod [0.23.5] #1882 records a Pod delete-handler panic on DeletedFinalStateUnknown in 0.23.5.
• Operator irregularly crashes and wipes all pods #671 records the same ConfigMap delete-handler panic, operator restarts, and disrupted ClickHouse pods.

This PR only makes existing delete callbacks safe. It does not enable the dormant CHI ReconcileDelete queue path or otherwise change deletion policy.

Fix

Routes both direct objects and DeletedFinalStateUnknown tombstones through a single typed delete handler in the CHI controller's informer callbacks, so malformed delete events are reported instead of causing panics. Includes regression tests for direct, tombstone, malformed, and nil payloads.

• decode direct objects and DeletedFinalStateUnknown tombstones through one typed delete handler, reporting malformed events instead of panicking
• protect all CHI controller informer delete callbacks
• add regression coverage for direct, tombstone, malformed, and nil payload cases

Test plan

• go build -mod=readonly ./...
• go test -mod=readonly -race -count=1 -vet=off ./pkg/controller/chi/...