Admin access docs for dynamic resource allocation overstate that non-admin users cannot misuse the feature

**This is a Bug Report**

**Problem:**

The [Admin access](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#admin-access)
section states:

> "Admin access is a privileged mode and should not be granted to regular users in multi-tenant clusters. Only
> users authorized to create ResourceClaim or ResourceClaimTemplate objects in namespaces labeled with
> `resource.kubernetes.io/admin-access: "true"` (case-sensitive) can use the `adminAccess` field. **This
> ensures that non-admin users cannot misuse the feature.**"

That last sentence assumes that setting the `resource.kubernetes.io/admin-access` label on a namespace is
itself an admin-only action. In practice it isn't necessarily: a common self-service RBAC pattern — granting a
team `get`/`patch` on only *their own* `Namespace` object (scoped via `resourceNames`), so they can manage
their own namespace's labels/annotations without broader `namespaces` access — is sufficient for a genuinely
non-admin user (no cluster-admin, no namespace-wide permission of any kind) to label their own namespace and
use `adminAccess`. This was live-verified; see
[kubernetes/kubernetes#141293](https://github.com/kubernetes/kubernetes/issues/141293) (closed as
working-as-designed at the code level, since RBAC intentionally gates verbs on resource types rather than
field values — this issue is specifically about the documentation's claim, not re-litigating that closure).

Separately, the dedicated
[Hardening Guide for Dynamic Resource Allocation](https://kubernetes.io/docs/concepts/security/hardening-guide/dynamic-resource-allocation/)
covers `resourceclaims/binding` and `resourceclaims/driver` synthetic-subresource RBAC in detail, but has no
mention of `adminAccess` or the namespace-label vector at all — despite this being the one DRA authorization
path that isn't gated by RBAC.

**Proposed Solution:**

1. On the Admin access section, soften/qualify the "ensures that non-admin users cannot misuse" claim — e.g.
note explicitly that any RBAC permission to modify a namespace's labels (even one narrowly scoped to a
single namespace via `resourceNames`) is sufficient to set this label, and that cluster operators should
treat `resource.kubernetes.io/admin-access` with the same operational care as Pod Security Admission's
enforcement-level labels (`pod-security.kubernetes.io/enforce`, etc.) — a comparison that isn't currently
drawn anywhere in the DRA docs.
2. Add a short section to the DRA Hardening Guide covering the `adminAccess` namespace-label vector,
parallel to its existing `resourceclaims/binding`/`resourceclaims/driver` coverage — recommending cluster
operators audit who holds `namespaces` `get`/`patch`/`update` permission (including narrowly
`resourceNames`-scoped self-service grants) in any namespace where `adminAccess` should not be usable.

**Page to Update:**
https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#admin-access
https://kubernetes.io/docs/concepts/security/hardening-guide/dynamic-resource-allocation/

**Additional Information:**

Filed as a documentation-accuracy issue, not a code bug — the underlying code behavior is already
working-as-designed per [kubernetes/kubernetes#141293](https://github.com/kubernetes/kubernetes/issues/141293),
which includes the reproduction supporting the claim above.

Start with the Admin access section in the Dynamic Resource Allocation documentation and the Dynamic Resource Allocation Hardening Guide, then review kubernetes/kubernetes#141293 for the verified RBAC behavior. Update both named pages to qualify the claim about non-admin users and document the namespace-label authorization vector, including narrowly resourceNames-scoped permissions; done means both pages accurately describe the risk and operator guidance.

Written by the indexing model from the issue text.