EventRecorder: default aggregation key, ownerReference support, and naming control #3601

Is your feature request related to a problem? Please describe.

The new EventRecorder is exactly the thing we've been hand-rolling in our operator for years, so 5.6.0 was the trigger to try to finally delete our own implementation. We got close, but three things stopped us. Raising them now while the API is still experimental, in case you're open to shaping it a bit further.

1. The message is part of the event identity by default. Our health events carry live detail in the message (current pod states and so on), so every message change becomes a new Event object. For this kind of "current status" event that's not great: old states hang around as separate rows in kubectl get events until the TTL cleans them up, and during an incident the object count grows with every distinct message. Now, EventRecord.key() already solves this nicely, we tried it on a real cluster and with a key set the repeats patch count, lastTimestamp and message in place, giving the classic (x12 over 3m) in kubectl describe. The catch is that key() has to be set on every single record. We have around 40 emission sites, and one forgotten key() silently falls back to one-object-per-message.

2. No ownerReference. There's no way to tie a recorded event to the resource it's about, so after someone deletes the CR its events stick around until the TTL expires.

3. No control over the event name. Names are always <resource>.<hash>. Our current events have predictable names (<resource>-<event-name>) and it turns out people actually rely on that, we found scripts doing kubectl get event <name>. So switching to the recorder as-is would break them.

Describe the solution you'd like

1. A default aggregation-key strategy at recorder or controller level, something like "aggregate by reason", so context.eventRecorder().normal(reason, message) just does the right thing without per-call setup. Per-record key() stays as the override.
2. An opt-in flag to set the ownerReference to the regarding object.
3. Let the record (or recorder config) supply the event name or a naming strategy, hash stays the default. A per-reason name gives you the same guarantees the hash provides (no collisions, stable across restarts and replicas), just readable.

Happy to contribute any of these if you like the direction. Also happy to split this into three issues if that works better for you.

Describe alternatives you've considered

Keeping our own implementation, which is what we're doing for now. It works, but it's ~100 lines plus tests that do what EventRecorder almost does, and we'd rather be on the SDK. A wrapper that injects key() everywhere would only fix the first point and adds a layer we don't want to own.