fix(event): handle typed nil in NotifyError to prevent build controller panic

[Diesel93]

Fixes #6587

Problem

When an action's Handle() returns (nil, err), newTarget is a typed nil *v1.Build. When passed as a runtime.Object interface parameter to NotifyError, the check newResource != nil evaluates to true because the interface has type information even though the underlying pointer is nil.

This causes recorder.Eventf → reference.GetReference → obj.GetObjectKind() to panic on the nil pointer, crashing the build controller on every reconcile. The build pod never spawns.

This was introduced in #6492 when migrating from record.EventRecorder to events.EventRecorder — the new recorder goes through GetReference whereas the old one did not.

Fix

Use reflect.ValueOf(newResource).IsNil() to properly detect typed nils before using the value.

Testing

Reproduced the panic consistently on 2.10.0 (Helm install, EKS). Built a custom operator image from this branch and deployed it to a live EKS cluster. Build controller completed a full build lifecycle without panicking — kit reached Ready state with a valid image reference.

Note: the e2e test suite won't cover this path as it only exercises the happy path where Handle() doesn't return (nil, err).

[squakez]

Thanks for the work and, indeed, the reflection would fix this problem likely. However it is not a cheap operation and we try to avoid as much as we can for that reason. I think I was the one that introduced the bug by mistake with this work #6556 - while refactoring I've abstracted too much and lost the original type reference. I will revert this and apply a patch soon.