reftracker: return a snapshot from AppsForRef / RefsForApp to fix concurrent-map panic

[SAY-5]

Fixes #1812.

AppRefTracker protects its internal maps with a sync.Mutex, but AppsForRef and RefsForApp returned a.refsToApps[refKey] / a.appsToRefs[appKey] directly. The caller (e.g. SecretHandler.enqueueAppsForUpdate) then iterates that returned map without holding the tracker lock:

apps, err := sch.appRefTracker.AppsForRef(reftracker.NewSecretKey(...))
...
for refKey := range apps {  // concurrent modifier can fire here
    ...
}

Under the reported production load (1,680+ namespaces, rapid Secret and ConfigMap churn, many reconcile goroutines) a parallel ReconcileRefs or RemoveAppFromAllRefs mutates the very same inner map the handler is ranging over, and the Go runtime aborts with

fatal error: concurrent map iteration and map write

crashing the kapp-controller pod.

This returns a shallow copy of the inner set from both lookup methods so callers can iterate without holding the tracker lock. The copy is cheap (refs per app is small in practice; the outer app-to-refs map stays unbounded either way), and the concurrent writers keep exclusive ownership of the originals. A small cloneRefKeySet helper keeps the two call sites in sync.