Describe the bug
When using informers, the initial list operation returns a V1PodList where the nested Pod objects do not have the kind and apiVersion fields populated (they are null). However, when the informer subsequently receives watch events, the individual Pod objects contain the expected kind (e.g. "Pod") and apiVersion (e.g. "v1"). This inconsistency in the returned data can lead to confusion and issues for applications that depend on these fields being consistently set.

Client Version
23.0.0

Kubernetes Version
1.30

Java Version
Java 17

To Reproduce
Steps to reproduce the behavior:

1. In your informer callback handler, log or inspect the received Pod objects.
2. Observe that during the initial list operation, the nested Pod objects have null values for kind and apiVersion.
3. Later, when the watch events are received, the same fields appear correctly populated.

Expected behavior
It is expected that all Pod objects processed by the informer should consistently contain the kind and apiVersion fields.

Additional context
This behavior leads to an inconsistency within the same informer callback - first receiving Pods with incomplete metadata followed by Pods with the correct metadata. This makes it harder to rely on these fields for subsequent processing, and it is unclear whether this is an intentional design choice for efficiency or an oversight in the client’s deserialization process. It would be beneficial if the client could ensure that the nested objects always include the metadata