Kubernetes app: OIDC extraArgs guards are coupled to the pinned Kamaji arg-collapse behavior #3541

The extraArgs collision guards added in #3539 (packages/apps/kubernetes/templates/cluster.yaml) are correct only while the pinned Kamaji build collapses duplicate apiserver flags into a map[string]string keyed by flag name (ArgsFromSliceToMap, last entry wins). Upstream removed that collapse in 26.5.2-edge in favor of a slice-based merge that keeps user duplicates, and packages/system/kamaji/Makefile make update auto-selects the newest -edge tag, so a routine bump silently invalidates the guards' premise: they would keep failing renders for collisions that can no longer happen. Whoever bumps Kamaji past 26.3.6-edge should revisit them.

Two more behaviors of the current pin worth knowing at bump time. resetKubeAPIServerFlags detects extraArgs changes by len(), so a same-count flag swap strands the old flag on the live Deployment; fixed upstream in clastix/kamaji@126fe65 (clastix/kamaji#1165), first tagged 26.6.2-edge. And user extraArgs go last into MergeMaps, so a user-supplied --requestheader-username-headers, -group-headers, -extra-headers-prefix, -allowed-names or -client-ca-file silently replaces Kamaji's managed value; the chart emits none of those, so it is a user-input hazard rather than a chart bug.

There is also a second pin: the collapse lives in the kamaji image (packages/system/kamaji), but the extraArgs field the guards read is owned by cluster-api-control-plane-provider-kamaji v0.19.0 in packages/system/capi-providers-cpprovider, which already flags an upcoming v1alpha1 to v1alpha2 rename. The in-tree comment currently names only the first pin, so a CP-provider bump would not point anyone at the guards.

Still open, from review of #3539, neither blocking. On v1.31 a hand-written --requestheader-uid-headers passes through untouched to an apiserver that does not know the flag and will not start, and the released v1.6 field doc named exactly that flag as the escape hatch; docs/oidc-tenant.md describes it now, which is not the same as closing it. And --requestheader-uid-headers=X-Remote-Uid, passes the chart's check while upstream's checkForWhiteSpaceOnly rejects the trailing whitespace — the chart reads the entry correctly and it is the operator's own value the apiserver refuses, so nothing is wrong as written.

Closed in #3539, each with the test that pins it. Gate names are compared exactly rather than case-insensitively (does not read a mis-cased gate name as ownership on v1.32). --emulated-version decides the gate rather than the image tag, in the bare spelling (follows --emulated-version rather than the image tag when deciding the gate) and in the quoted one, where the chart now renders nothing (renders nothing when quotes hide the emulated version from the chart). The v1.32 cell with a conforming header entry and no --feature-gates entry has its pinning test (renders the standalone v1.32 gate for a conforming header entry with no gate entry).