fix(k8sinterface): reload client config on cluster context switch

SetClusterContextName only updated clusterContextName. IsConnectedToCluster
and GetConfig each cache their result (K8SConfig, clientConfigAPI) and only
(re)load when that cache is nil, so switching to a different context left
both caches pointing at the previous context: GetContextName() reports the
new context while GetK8sConfig() keeps returning the old one's server, with
no error raised anywhere. A caller iterating over several contexts in one
process gets cluster A's data labelled as cluster B.

SetClusterContextName now invalidates K8SConfig and clientConfigAPI whenever
the requested context actually differs from the current one, so the next
GetK8sConfig/GetConfig call reloads for the new context instead of serving
the stale one. Repeated calls with the same context stay a no-op, so the
single-cluster-per-process case (the common one today) keeps its existing
caching behavior unchanged.

connectedToCluster is also reset to true on a real context change: it is
only ever set to false, never back to true, so a load failure on context A
would otherwise permanently suppress IsConnectedToCluster() for every
context scanned afterward in the same process, even a perfectly reachable
one.

This is scoped to the client-config/kubeconfig state only. A related but
separate cache, the API discovery snapshot behind InitializeMapResources,
had the same class of bug (#159) and was fixed independently in #160 since
its root cause and fix shape differ.

Closes #158

Signed-off-by: Lalit Kishore <lr_be24@thapar.edu>