Clarify documentation for ValidatingAdmissionPolicy and contents of CEL context (#52303)

* Unclear documentation for ValidatingAdmissionPolicy and contents of CEL context #39368

Subject: docs: Clarify accessibility of metadata properties in CEL

The current documentation states that "No other metadata properties are accessible" besides name and generateName. This is misleading for users of ValidatingAdmissionPolicy, as the strongly-typed object variable allows access to all metadata fields like labels and annotations.

This PR clarifies the behavior by:

Stating that the object variable is strongly-typed and allows full access to all schema-defined fields.
Rephrasing the original statement to explain that apiVersion, kind, name, and generateName are the guaranteed minimal set of fields available for any object, which is the original intent of the sentence.
This change prevents confusion for new users and more accurately reflects the capabilities of CEL in this context.

* Update validating-admission-policy.md

* Update validating-admission-policy.md

* docs: Wrap long paragraph for readability。

Author: ninglonglong

content/en/docs/reference/access-authn-authz/validating-admission-policy.md

@@ -330,9 +330,12 @@ variables as well as some other useful variables:
 - `authorizer.requestResource` - A shortcut for an authorization check configured with the request
   resource (group, resource, (subresource), namespace, name).
 
-The `apiVersion`, `kind`, `metadata.name` and `metadata.generateName` are always accessible from
-the root of the object. No other metadata properties are accessible.
-	
+In CEL expressions, variables like `object` and `oldObject` are strongly-typed.
+You can access any field in the object's schema, such as `object.metadata.labels` and fields in `spec`.
+
+For any Kubernetes object, including schemaless Custom Resources, CEL guarantees access to a minimal set of properties:
+`apiVersion`, `kind`, `metadata.name`, and `metadata.generateName`.
+
 Equality on arrays with list type of 'set' or 'map' ignores element order, i.e. [1, 2] == [2, 1].
 Concatenation on arrays with x-kubernetes-list-type use the semantics of the list type: