feat: add cluster uid derived from kube-system ns

[SgtCoDFish]

This seems like a simple enough way of uniquely identifying a cluster. Google searches show that this pattern is used elsewhere.

It seems fair to assume that if the kube-system ns UID changes, it implies that the cluster changed enough to be considered different anyway!

This is added to the context so it can be used elsewhere, on the assumption that it can be determined at startup and won't change later. We'll use this for "machinehub mode" soon.

Possible work still needed (i.e., we need to decide if the below are acceptable before we merge):

• Is it OK to hard-fail if we can't determine this on startup (i.e. if the agent isn't run in a k8s cluster or we don't have permission to get namespaces)?
  • Probably not; we might need to add a dummy value if we can't determine the UID
  • Also, that means that MachineHub mode won't work
• Should we add the option to error if unable to retrieve the UID from context, instead of panicing?

[wallrj-cyberark]

I've tested this and observed the new clusterUID is logged at startup, with a GKE cluster:

$ ./hack/e2e/test.sh
...
{
  "ts": 1753372212871.0688,
  "caller": "agent/run.go:101",
  "msg": "Retrieved cluster UID",
  "v": 1,
  "logger": "Run",
  "clusterUID": "da59b2ea-a06f-4c7f-bb91-038222eb6f73"
}
...
{"ts":1753372219356.0215,"caller":"agent/run.go:460","msg":"Data sent successfully","v":0,"logger":"Run.gatherAndOutputData.postData"}
...

$ kubectl get ns  kube-system -oyaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2025-07-24T14:35:50Z"
  labels:
    kubernetes.io/metadata.name: kube-system
  name: kube-system
  resourceVersion: "1753367750128975004"
  uid: da59b2ea-a06f-4c7f-bb91-038222eb6f73
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Is it OK to hard-fail if we can't determine this on startup

I don't think that's acceptable. The cluster UID is only needed for the machinhub integration so it should at least be confined to that branch.

Should we add the option to error if unable to retrieve the UID from context
Yes, I think so.

I won't merge it until we have a branch ready to show how this will be used.

[wallrj-cyberark]

I've been testing this in #678 and it works well.
I'll remove the temporary panic statements in a followup PR, along with some other changes to the Machine Hub / Discovery Context API wrapper