Describe the bug

Headlamp's useGet (via useKubeObject) can fail to retrieve resource details when a user has get permission but does not have list permission for that resource.

The current implementation of getWorkingEndpoint probes the collection endpoint (for example, /apis/apps/v1/namespaces/default/deployments) using a GET request without a resource name. In Kubernetes RBAC, this is authorized as the list verb. As a result, users with only get permission receive 403 Forbidden during this pre-check, even though they are authorized to get the specific resource by name.

Expected outcome:
Users with get permission should be able to open resource details even without list permission, similar to kubectl get <resource> <name> behavior.

To Reproduce

Steps to reproduce the bug:

1. Create a Role with get permission for a resource (e.g., services) but without list.
2. Bind the Role to a user and log in to Headlamp.
3. Open the details page of a specific resource.
4. The page fails to load due to a 403 error from the collection URL probe.

Environment (please provide info about your environment):

• Installation type: Helm (In-Cluster)
• Headlamp Version: 0.39.0
• Other: Kubernetes RBAC enabled.

Are you able to fix this issue?

Yes (I will propose a PR)

Additional Context

• Root Cause: useKubeObject() -> useEndpoints() -> getWorkingEndpoint() performs a clusterFetch against a collection URL, which K8s maps to the list verb.
• Affected Resources: Primarily resources with multiple API version candidates (e.g., Ingress, Gateway, or CRDs) where useEndpoints performs preflight probes.
• Comparison: Tools like kubectl and ArgoCD successfully handle this by targeting the name-specific GET path directly.
• Scenario: This is critical in multi-tenant environments where list access to certain resources/CRDs is restricted for security reasons.