The 401 handling is what brings an expired session back to sign-in,
and a regression in it stays invisible until a cookie expires. The
test drives K8sClient through the vi.stubGlobal("fetch", ...) harness
the sibling k8s-client tests use. It checks that the hook fires once
per 401 from both the request and the watch fetch sites, once across
concurrent 401s, never on other responses, and that the default
handler passes the current location as a relative rd, which
oauth2-proxy's open-redirect check accepts.

Assisted-by: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>
(cherry picked from commit badbec6)

The dashboard gatekeeper runs one of two mutually exclusive proxies,
chosen by the cluster's oidc-enabled flag (templates/gatekeeper.yaml).
/oauth2/start exists only in oauth2-proxy. The token-proxy branch
registers only sign_in, sign_out and userinfo under the /oauth2
prefix, so there /oauth2/start falls through to the catch-all
reverse-proxy handler, which does not re-verify the token. With a
present but expired cookie it proxies the request to the console
upstream, the SPA reloads, gets a 401 again and loops.

/oauth2/sign_in is the one entry point both modes implement, so the
default 401 handler goes there. oauth2-proxy's sign_in hands straight
off to OAuthStart because the gatekeeper passes --skip-provider-button,
and it resolves rd through the same app-director, so the OIDC path
behaves as it does through /oauth2/start. token-proxy serves its token
form there. It does not honour rd yet, so after sign-in the user lands
on / instead of looping.

Assisted-by: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>
(cherry picked from commit 7e5f9ab)

unauthorizedHandled was set once per client and never cleared, so it
collapsed every later 401 too, not just the concurrent ones it was meant
to. Harmless for the shipped default handler, which navigates away and
takes the client with it, but the onUnauthorized hook exists precisely so
a caller can re-auth in place, and such a handler would fire exactly once
for the client's lifetime and then go silent.

Clear the latch on any 2xx from either fetch site: a success means the
session is alive again, so the next 401 is a new episode. The storm guard
still holds, since concurrent 401s have no success between them.

Assisted-by: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>
(cherry picked from commit b6c3392)