[backport v2.14] [BUG] ext.Kubeconfig doesn't fully behave like a standard Kubernetes API resource

This is a backport issue for #56315, automatically created via GitHub Actions workflow initiated by @pmatseykanets

Original issue body:

Problem

The ext.Kubeconfig store deviated from standard Kubernetes API behavior in ways that break generic kubectl-style clients:

• Backing-store errors were rewrapped as 500s on create and update: a stale-resourceVersion conflict never surfaced as 409, throttling lost its retry-after hint, and error messages named the backing ConfigMap.
• A dry-run update reported success without evaluating the resourceVersion or the caller's UID precondition, so a preview did not predict the real outcome.
• Delete removed the ConfigMap before its tokens and stopped at the first token-deletion error. The token list lived only in the ConfigMap, so the remaining tokens stayed valid with no record and no retry path.
• Collection deletes rewrapped per-item errors as 500s and aborted when an item was deleted concurrently.
• Set-based, inequality, and existence label selectors failed with a 500.
• The watch fan-out sent on a channel while holding a lock its teardown needed, deadlocking once a slow consumer's buffer filled. Bookmark events leaked an internal bookkeeping annotation.
• Every update appended another Updated condition, growing status.conditions without bound.
• The godoc/OpenAPI did not document server-generated names, the Rancher-token requirement for Create, or that the generated kubeconfig value is available only in the Create response; the cluster list serialized as null when empty.